Example Project

The prompt given to each was:

create an app that uses the spotify api to get a song, when given a voice command to get a song of a faster or slower tempo than the current song

The reason I used Spotify is that it does provide the tempo of a song, whereas SoundCloud for example does not - see my other post comparing the two APIs.

I also kept the prompt pretty vague, so wanted to see how it would fill in the gaps - for example, was there an an initial song, and how would it get songs?

The process, after entering the prompt in to each one:

Both the voice recognition parts work - and use the browser's native Web Speech API, so no extra library needed. The sound is usually processed on the cloud, rather than on device, for example for chrome.

v0 UI

Replit UI

From a product point of view, for the first pass of each app:

• v0 has a search bar which I didn't ask for but like
• Replit has buttons as a fallback for the mic which are nice
• Replit also has tiles for the next song depending on what you last did - but I had to fix it to work via prompts as initially it showed the same song

More Generally

Of note is that v0 is known for making UIs - and comparing the two more generally, not just for this project:

To note is that:

• Vercel also created Next.js.
• The use of Tailwind CSS and shadcn makes sense for AI - shadcn/ui allows you to edit component code rather than use a library, and tailwind makes styling composable text which AI is good at
• I asked replit to create a fitbit watch face - which requires a very certain stack, the fitbit sdk - and it simply said it would make me a web app for this, which was disappointing. For this, things which assist coding, rather than generate entire apps, are better, such as Cursor, GitHub Copilot etc.

When I think of both the first things that come to mind are that Spotify has certain features only on its desktop version (like making folders for playlists, which can then show on mobile), and Spotify does not allow adding metadata like notes, which SoundCloud does.

SoundCloud started in Berlin in 2007 as a platform for musicians to easily share and collaborate on audio files. Spotify was founded in 2006 in Sweden to built to combat music piracy.

Which got me thinking about the differences, which include:

In summary, SoundCloud is more for creators and music discovery, while Spotify is more for mainstream listening convenience.

API Differences

Getting more in to the details of the APIs:

Another thing to note is that Spotify locked down a lot of endpoints with data - likely because it could be stolen and it is IP. It does mean less data for any hobby projects though!

In another post I'll use the Spotify API in a project!

GitOps is code-based infrastructure and operational procedures that rely on Git as a source control system. It’s an evolution of Infrastructure as Code (IaC) and a DevOps best practice that leverages Git as the single source of truth, and control mechanism for creating, updating, and deleting system architecture.

What is flux:

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.

I have been in a position where I was familiar with kubernetes and helm, but not flux. I was viewing helm logs, that were generated by flux, and began to wonder how they were actually generated. Turns out that flux has controllers and there is a helm controllers that controls this.

I even asked about it in the online community, and got examples like:

• this ring buffer logger
• an example of it being put to use
• persistence to event data

Other than logs, things can also be captured in events for the HelmRelease object.

Overall, flux is an interesting product, and seems to not be going anywhere despite its parent company shutting down.  

Observing a System

Software engineers often spend a large amount of time trying to solve user issues that might not be easily reproducible. Sometimes, system logs don't have enough information and one is left guessing at what happened, using a process of elimination while reading code, to guess what happened.

In theory, we should be able to pin point any issues in the code from outputs of the application - that is, you should be able to tell the internal state of a system, by observing it.

This is where observability comes in to the picture. The Wikipedia definition is:

In software engineering, more specifically in distributed computing, observability is the ability to collect data about programs' execution, modules' internal states, and the communication among components.^[1][2] To improve observability, software engineers use a wide range of logging and tracing techniques to gather telemetry information, and tools to analyze and use it. Observability is foundational to site reliability engineering, as it is the first step in triaging a service outage. One of the goals of observability is to minimize the amount of prior knowledge needed to debug an issue.

Example of an Issue

An example of an issue that could not be reproduced is intermittent duplicate API calls being made by the browser after a user clicks a button to submit information.

The metrics, logs and traces, were not detailed enough to provide the reason why this was happening. The API call was made idempotent to ensure the API call submission only changes state once, which meant that the user was ok and that form submission only happened once.

But let's dig in to what could be observed:

• browser network tab - shows one call
• front end library that does the post - middleware showed two posts
• network gateway logs show two posts
• infrastructure (kubernetes - service and pod) logs showed nothing unusual
• application logs show two posts, sometimes on two different kubernetes pod

Even with all this information, nothing could pin point the issue.

Developer Experience

The above scenario is like looking for a needle in a haystack, which is not fun, and should not be the case with well developed apps.

You might resort to a process of elimination, and asking why 5 times, like in a retrospective.

To add to the haystack, application logs may also use non-standard terms, or even use existing standard terms for other purposes (like correlation id and span id), as many libraries are catching up with Open Telemetry such as those noted here and here.

The answer to at least make the haystack clearer, is OpenTelemetry.

OpenTelemetry

OpenTelemetry is:

An observability framework and toolkit designed to facilitate the

• Generation
• Export
• Collectionof telemetry data such as traces, metrics, and logs.
• Open source, as well as vendor- and tool-agnostic, meaning that it can be used with a broad variety of observability backends, including open source tools like Jaeger and Prometheus, as well as commercial offerings. OpenTelemetry is not an observability backend itself.

A major goal of OpenTelemetry is to enable easy instrumentation of your applications and systems, regardless of the programming language, infrastructure, and runtime environments used.

So the lesson is - use OpenTelemetry!

This post lists some ways to communicate "technical things".

Analogies

Use the following analogies of the state of things:

• a clean room needs regular cleaning, though if one day is missed it won't make a difference
• a working car needs regular maintenance, though if one day is missed it won't make a difference

Use the following analogies for habits:

• going for a run or going to the gym - missing one day is ok, but not every day.

It's the same with technical debt. Missing it for a day won't make much impact, but if it is never done, the results will build up and negatives will surface.

Business Impact

Communicate any of the below impacts:

• speed - such as every feature taking longer to build if we have outdated code
• blockers - such as tech debt of deprecated libraries meaning they aren't supported anymore and can post security risks, and that won't work with other components
• reliability - unresolved tech debt increases the risks of outages or bugs, which can impact customer negatively
• cost - the longer we delay addressing tech debt, the more it expensive it becomes to address

Present a Plan

• Break down the work in to manageable tasks
• From the above business impact points - show how investing time in tech debt will increase efficiency, reduce costs or enhance stability
• suggest a phased approach such as 20% of each sprint being tech debt

Provide Evidence

• Show metrics such as customer complaints and slow delivery times
• Demonstrate past successes of addressing tech debt

Tie all of the above to business goals like lower cost and better use experience.

Another definition is that it is user-defined data field within a software system that allows users to store and organize additional information specific to their needs or business processes.

You can find examples in many places such as in JIRA, travel websites (listing custom fields for hotels for example) and a lot of customer relationship management (CRM) software.

In this post, let's discuss, how you would design a solution for this, at the high level.

Requirements

• store key value pairs for an entity like storing that a pool (value) is an amenity (key) for a hotel (entity)
• definitions to be set up by admin
• values to be entered by user
• values to be of many types such as text, date, boolean and multi list (both single and multi select)

Database Design

You could use any type of database. But let's say you are bound to a relational database.

One solution is to have a table for each of:

• the custom field definition
• the custom field value, if it's not a multi list
• multi list options
• for multi list custom fields, a bridging table to list chosen list options for a custom field

For tables, design the following for your use case:

• have native data types for each of the data types (such as text, date, boolean) as this will prevent problems later with data integrity, and make data selects easier such as when selecting a date range with actual dates, rather than text that has to be cast to dates for a select
• why data types were chosen and the length of each field
• uniqueness and constraints
• sorting and indexes

Design Considerations

You should limit the number of custom fields so that users

• don't exploit it (for example if it's free as a data store). A higher limit could have a fee to prevent that if needed.
• don't put a high load on infrastructure that it is not designed for
• won't have a UI that was not designed for, say with thousands of custom fields on the page if it's not designed for that.

You should also validate the name of the custom field to ensure the name is not an existing name via blocklist, as otherwise it will look like a non custom field to the user on the UI (unless there is a visual difference for custom fields, but let's assume there is not).

Since deletion by accident is a big loss for customers in for example CRMs where they have put in effort to input the data - to protect against that you should, on delete, have a UI warning, and do soft delete (in addition to any audit tables).

For security, you should also sanitise input to protect against injection attacks.

For all these things be clear on who is making the decision, such as whether it is product or tech.

Balance of Work

In times like this, work competes between fixing the bugs, doing product work and doing tech debt work. So how do you balance these? You balance these by "spending" an error budget.

An error budget is is the maximum amount of time that a technical system can fail without contractual consequences. So you can simply use that, to gauge whether you have to address bugs. But, for that you need SLOs and SLAs.

From the above link:

Error budgets aren’t just a convenient way to make sure you’re meeting contractual promises. They’re also an opportunity for development teams to innovate and take risks.

The development team can ‘spend’ this error budget in any way they like. If the product is currently running flawlessly, with few or no errors, they can launch whatever they want, whenever they want. Conversely, if they have met or exceeded the error budget and are operating at or below the defined SLA, all launches are frozen until they reduce the number of errors to a level that allows the launch to proceed.

If you don't have SLOs and SLAs, then the error budget might be a bit more subjective. If you always have a contract of 80% feature work and 20% tech work as is common in many companies, this might be all you have to deal with.

Morale

The morale might not be affected if it's a high performing team with a blame free culture. But for teams that might be newer or less mature, you might need to tread carefully before openly discussing there being too many bugs. To make the conversation more objective, try to use the above to steer the conversation. But even with that, if you are in a team with a 80% feature work and 20% tech work split, but there are so many bugs that you spend 80% of the time fixing bugs, then you need to have a conversation with key stakeholders and leadership to make people aware of what's happening so that expectations are met.

Let's break that down. A textbook answer would be:

• lots of unit tests in the application
• fewer integration tests like postman tests
• even fewer end to end tests like cypress tests

However, I don't agree with that answer.

On the unit tests - they can be a by-product of test driven development. But once they exist, they may not be needed if integration tests are sufficient to test the inputs and outputs of the system. In fact, if large scale refactoring is done, then a disadvantage would be that unit tests would also need to be refactored. While integration tests would not need change with a large scale refactoring because they don't rely on the internal implementation. Inputs and outputs are

On integration tests - testing all business cases is what is relevant. Instead of all possible permutation to meet 100% code coverage.

On end to end tests - they are the final piece to avoid manual testing and are super useful.

So to answer how many tests are enough - again, it's enough to feel confident. And that may not need to include unit tests at all.

In fact, I came across crazy stories where laptops are not configurable for the user, where noise cancelling is permanently on, to the point that a user cannot transmit/record playing a musical instrument over their laptop microphone, because the instrument is filtered out and they cannot do anything about it, not even by configuring anything differently.

I had a similar issue when using voice control where a "pop" sound was filtered out by the microphone configuration, but I required it to be transmitted via the microphone.

So this post is a quick reference on how to turn off noise cancelling if your laptop allows it - and since the menus here are so comprehensive, it's also a reference for how to configure microphones in general. It also mentions how to configure gain (amplification) which can fix a lot of setup issues. It is Windows based.

"New" Windows Menu Sound Settings

Select the microphone below, and ensure audio enhancements is off. Also make "input volume" the max (this is software gain and should change the old control panel, but sometimes does not).

"Old" Control Panel

In the old windows menu (Control Panel > Hardware and Sound > Manage audio devices) on microphone, double click specific microphone, go to advanced and untick noise cancelling if it's there - untick "enable audio enhancements". Also in tab "levels" (this is software gain) - set the gain to high:

Other Software

A lot of laptops come with OS software (like DELL) that includes the microphone, or various brands like audio max pro, alienware command centre etc. Ensure you've checked all the settings in those too. Note that if such software is uninstalled - it may still have a service running somehow, so check that, and stop the service if needed.

Also check any custom software like those which allow you to mute and unmute via a user interface.

If you have an audio interface which I've had in the past, and have a fancy mic, you will likely have even more software and configuration available, so check all of their options.

But at so many companies it is a whole lot longer with a whole lot more steps, say 20 steps and 1 hour. The question then is, how to reduce deployment time. Let's define a few things before we get to that.

How Often Should You Deploy and Why?

One of the DORA (DevOps Research and Assessment) metrics is frequency of deployments.

Various sources all point to the following:

• High-performing teams can deploy changes on demand, and often do so many times a day.
• Lower-performing teams are often limited to deploying weekly or monthly.

But Why

Deploying frequently has many benefits, let's list just a few here:

• smaller changes means less risk, and incremental QA, and teams being agile to break work down
• no merge conflicts or other dependencies that come with larger waterfall releases

So the answer is - ideally, you should deploy many times a day because it is agile and reduces risk.

One Deployment per Day per Team - Reality or Just Theory?

The Industry

I have asked people I know if teams deploy once per day, and the answers I got were:

• people at large tech companies said yes, they deploy at least once a day per team. They have no manual QA and commits to master are deployed to prod automatically.
• but most people said 1-2 deployments every 1-2 weeks.

I personally have been in both kinds of teams above.

How Not To Reduce Deployment Time - KPIs

Many companies set up things like KPIs to deploy to prod every day, especially if their deployment times are long, to drive down the deployment time.

Good Intent - But Often Achieves the Opposite

While this KPI has good intent, because it is a KPI, this prioritises people to meet the KPI today, tomorrow, and the next day, and every day of their working lives - and it prioritises that over actually reducing deployment time. That is the core issue with such KPIs. The KPI may thus actually achieve the opposite of what it intended to achieve.

Additionally, people might not just deploy daily, but they may game the system to achieve more releases - such as deploying code without value, striving to deploy only things which are microservices and likely to have more deployments (over a monolith), having more people in the team meaning there are more deployments per team - etc.

So often what happens is that people do whatever it takes to meet the KPI, even if this includes wasting time. That wasted time could instead have been spent reducing deployment time. As for how to do that - it's in the next section!

Positives and Negatives of the KPI

Let's imagine if the KPI was abolished. Teams may then no longer care about deployment time. So there is reason to the KPI - to force people to be frustrated to the point that they take action themselves. This however can lead to employee disengagement and burnout.

So it's a lose-lose situation. If you keep the KPI, teams are wasting time. If you abolish the KPI, teams may not reduce deployment time.

Perhaps what's needed is other goals - to simply reduce deployment time.

How To Actually Reduce Deployment Time

Other Company's Journeys

Various online journeys include:

• HubSpot - they removed any manual steps
• Monzo - they optimised engineering culture, tooling, and architecture

None of these journeys mention a KPI.

They mention metrics - but those are app metrics, not team metrics.

Quick Wins

A team alone can get some quick wins, which a KPI would drive, including:

• automating messages to chat channels when release happens, or a pr is raised
• having feature flag toggles that take effect instantly
• optimising build pipelines, for example to run steps in parallel, to cache relevant things, and to make tests run faster

Longer Term Gains

A team alone can't achieve the larger cultural and process shifts needed for big reductions in deployment time - a KPI likely won't drive teams to this - unless maybe a few individuals step up and take ownership in addition to their normal work:

• commits in master deploying to prod automatically
• no manual QA
• a DevOps culture - closer collaboration and a shared responsibility between development and operations for the products they create and maintain

If It's Not Working

If teams are trying to reduce deployment time but it's not working, ask:

• are devs not automating tests, and why
• what is the complexity of system
• are there any integration tests
• is the culture such that people think deployments need a "human touch"? Such as letting people know of  a big release hours/days in advance - this can still happen with daily deployments, via usual communication and collaboration.

Closing Notes

All of the above needs to be taken in to context - sometimes you don't deploy to prod for weeks, because maybe you are designing something, and sometimes you deploy to prod several times a day. Ideally though, things are at least set up for frequent deployments.

History of Microservices

The buzzword seems to have existed since the early 2000s, but Netflix seems to have pioneered the usage of microservices around 2008. They became popular due to their high scalability.

Definitions

Microservice

Wikipedia defines microservices as:

In software engineering, a microservice architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols.

What's a bit odd is that there is almost no mention of consistency and messages- perhaps they wanted to keep implementations as abstract as possible. But I disagree with that. Some mention of them is required.

This talk is what I would consider as more accurate than the above definition. It's an hour long, but well worth watching.

A good definition from it, is that microservices:

• are composed of small and loosely coupled services, which can be deployed independently
• are services that communicate via messages on the back end
• are owned by small and well contained teams.

Monolith

To put things in to perspective, the definition of a monolith is that it is built and deployed as one piece, eg changing one thing requires deployment of the whole piece.

Pros and Cons of Microservices vs a Monolith

Advantages of microservices

• high availability
• encourages writing loosely coupled code
• encourages agile processes and teams that are experts in different parts of an application

Advantages of monoliths

• typically has better data throughput (not necessarily performance) - eg time for an update from front end to back end
• scalable eg via load balancing, adding more memory or cores, virtual/physical hardware changes, for databases could use data sharding
• immediate consistency

Disadvantages of monolith

• one piece is one tech stack - could be advantage too though
• is not as agile a process as building a microservice
• cannot have small teams focussed on one area

What Exactly is Monolithic? Either the Logic or Physical App

There are 4 combinations of the logic and the physical app, being either monolith is or distributed, and these are:

• if code is modular, and app is physically distributed, it's a true microservice, which is good
• if code is a monolith, and app is physically a monolith, it's a ball of mud monolith, which is bad
• if code is modular, and app is physically a monolith, it's a modular monolith, which is good
• if code is a monolith, and app is physically distributed, it's a distributed monolith

Note on the Distributed Monolith

• always performs worse than monolith or microservices
• more difficult to maintain
• often has one database - which becomes a bottleneck with a lot of microservices hitting it

When You Should use Microservices

Only if you have a good reason, eg in the case when:

• monoliths are bad or unscalable
• microservices are hard to do well
• Wrong reasons create distributed monoliths

Good reasons to create them:

• more scalability
• independent deployments
• isolate surface area of failure

The trade off is that microservices have high availability, but low consistency. Monoliths have immediate consistency, but low availability.

The Wording

What is more accurate, is to make an educated estimate, rather than just "an estimate". The change in wording makes it clear, that it is an informed thing, rather than a concrete, never changing thing.

The Audience

You should ask yourself for whom you are making the estimate as this will likely tell you why you are making it, so that you can include the right level of detail:

• yourself - to plan out your own work relative to other work
• your direct manager, who might report it on to others who report it to the business
• project manager, CTO, other colleagues - to report back to the business

For example, you might want a breakdown of the estimate, that you can sum up. But a CTO may want a one word answer for how long something will take.

The Details

On the note of level of detail - a surprising number of people are simply not organised and don't have much level of detail. If you do, it is a gift. However, with such a gift, you don't always want to share a long story about the breakdown of an estimate.

If you have details, summarising them in to a word or sentence is a skill in itself also.

That Quantified Estimate

Once you have the details of an estimate, you will have to quantify them somehow, in order to then later be able to summarise it all. Different teams estimate in different ways such as assigning:

• story points
• t-shirt sizes like extra small, small, medium, large, extra large
• amounts of time, like days or weeks

To do this, a benchmark of previous work is always useful, such as what it means for a story be 5 story points.

What is Actually in an Estimate

Usually estimates are just a measure of the "raw work" in question, and do not include overhead like:

• public holidays, leave
• other overhead like meetings, learning

But such overhead is crucial when mapping an estimate to an actual date that work might be finished by a team, so these things do need to be considered. The good news is that overhead is generally easier to predict than an estimate of work.

To add overhead, you could manually try to add some number of hours or days of known overhead to the estimate.

But some of the best people I know take an estimate, and simply double it before presenting it. It can be hard to defend this with reasons - but a lot of the time some multiplier, like x1.5 or x2 is used to add in both risk mitigation for the actual work, plus overhead, in order to arrive at a final date that work might be completed.

Large Estimates

Large estimates should definitely be broken down, as the higher the estimate, the bigger the margin of error, and also because work generally should not take longer than a sprint to complete, to avoid it dragging on.

How Long to Spend Estimating

An important point is that there is always a level of risk in estimating, and that we should not spend too long estimating.

The Final Educated Summarised Estimate

A final educated estimate might look sound like having a goal of delivering by the end of month including any public holidays, leave and other overhead.

Reflecting on Estimates

Back on the concept that estimating is a black art -  when asking others for examples of past estimates, you may find that there are none to share which is a bit mysterious. Or you might be told to check the backlog - although, it's often impossible to tell with tickets that are done, how long something actually took.

Team retros are a good place to discuss reflections on work, or separate meetings.

Further Reading - More Sophisticated Methods

Estimation is a field of its own, and one of the best estimators I know uses the forecasting tools. I won't elaborate on the below - but just leave them here for more reading!

1. Simple Monte Carlo forecasting - works on a count of backlog items

2. Throughput Forecaster (excel file) - has metrics like backlog items and velocity

While it might sound simple, a lot often goes on, particularly in weighing up business priorities, timelines and clarifying what is at hand.

Generally most batman bugs should go in to BAU (business as usual bugs) for review, unless there is a business reason that it is urgent.

Once an issue or query is found, to work out the priority it's always good to ask:

• how does this affect the business eg is there a loss of money or reputation?
• to tease this out in more detail, you could also ask  what is consequence if we do not fix/investigate this?
• is this an existing bug?
• how long might it take to fix?

It's also good to define what Batman might be. For example:

• As hinted at above, Batman is a way to scope ad-hoc work to one person, rather than the whole team - but there is nothing else specific to the batman role.
• It is just a person that is expected to be the point of contact for external requests during a sprint.
• Batman is there to handle anything that is not in the current sprint.
• Batman also completes any urgent work deemed to be part of the sprint after the triage process.
• Batman should respond to questions on chat channels.
• The work that is in testing is part of the current sprint, and the tickets are already assigned. It is not Batman's job to ensure everyone is updating JIRA tickets. Though when issues come up related to recent work, having up to date JIRA tickets can be invaluable, so Batman might ask team members to update JIRA.
• It is also not Batman's job to pick up any bugs raised by testers which occur as a result of current sprint work. Developers should test everything. PRs should obviously only be submitted for code that has been tested by the developer, and that works and satisfies acceptance criteria.
• Testers are the last line of defence, they are there to test more scenarios not picked up by unit, integration and functional tests, potentially taking more time to do - but the code should already satisfy the basic requirements of the story.
• Batman may end up in conversation with testers due to ad-hoc questions, but if a question is related to an existing ticket, Batman is fine to pass those questions on to the relevant person working on the relevant feature.

Once something is found, elaborating on the above initial questions:

• For things that are deemed significant enough, we can reach out to the business, like the product owner, to check if they can/should be done in the current sprint.
• For the ones that we deem to be just minor bugs, they can just be in the backlog, with sufficient information - without explicitly bringing them to Product Owner's attention.
• For the ones that we may deem to be worthwhile resolving in the short-medium term, we may want to advocate for their inclusion in an upcoming sprint. The Product Owner should be looking at the backlog and prioritising on a regular basis anyway.
• A lot of the discussion specific to individual bugs could take place in JIRA comments - whether it is batman summarising what the current question/conclusion is, or whether it is tagging people to ask a question.

If tasks that entered the sprint end up being dragged into multiple sprints - it is probably up to the team to decide whether to treat those as ad-hoc work for Batman to verify, triage and possibly fix, or whether to create a new ticket.

All that being said, all the above are initial guidelines. It is fine to be agile, for example to pull something in to the sprint with good reason, but then pull it out later if new information comes to hand. The key is always to have solid reasons and lines of communication.

Here is another! It is split in to sections.

As a priority though, before getting code free of tech debt and perfect, one should deliver and deploy the business value first if needed, then right after refactor as needed.

Straight Forward Checks

For future proofing:

• does this work fit in with the future tech direction
• enable new features of the language if relevant
• ask if the best libraries for the use case used

The basics which need a bit of thought:

• when passing an object in code - it is good to pass the whole one, as signature then won't know about granular workings, and also if is changed in future to use other properties in it, signature won't change - but case by case basis, you can also pass minimal info in
• is the code well tested? Not just are there tests at all, but are the tests ones which would need to be re-written if the implementation changed? Is there a more future-proof way to test this?
• test at business level, abstract only when need to, avoid mocking if appropriate

The basics most of which can be or are automated:

• anything that would be a intellisense suggestion
• follow best practices
• formatting
• add documentation to methods, even architecture decision records

Feature Specific Things:

Have all of these been considered:

• any service should be a  “technical authority for a business capability"
• domain driven design should be used if appropriate (but don't use things without reasons or because they are buzzwords!), with bounded contexts mapped out
• when naming tests - name as per business, not as per data transfer objects or random properties in the code
• Things that change together live together

Simplicity/Clarity:

• in the pull request description, have you provided a reasonable amount of detail? a good structure is to state functional changes (actual changes to the user) and structural changes (no changes to the user, structural code changes only such as refactoring)
• is the pull request too large
• would this code be confusing to a new hire? Is there a way to make it simpler or easier to understand?
• does prep work need to be done eg refactoring?
• is there a better way to structure this code? Is it following best practices?
• is the code grouped in a way that makes sense? Is the data stored in the best way? e.g. including timezone info for datetimes, using a structured format (as logging fields, or db files, json fields) instead of encoding as (unstructured) string.
• is something being written from scratch when there is a library that would solve this?

For When You are The Reviewer

And lastly, obviously, it's always best to check out the code in an IDE when reviewing others' pull requests.

Ask another, and maybe they will say that mastery and autonomy are the key.

Look around and maybe you will see people leaving companies in the pursuit of titles, and even sometimes going back to their initial company with a title change.

But what does all that mean, and how can you progress yourself?

From various sources, the below seem to be reasonable, to be senior, for a software engineer.

It is worth noting that one does not don't need to meet all of these to be senior, they're all different skills that makes the difference between senior, mid and junior. A lot of these skills come with experience but not everyone makes the effort to learn them so years of experience aren't always a good measure.

The core needs seem to be:

• technical skills - can you pick up almost all tasks and get them done with minimal support? Note that this is support and not discussion - you might need to work with other seniors or team members to decide on the approach, but you understand the issue, bring some ideas of your own, and probably have specific questions rather than vague “how to…” type ones.
• project skills - can you get given something broad and not deeply defined and get it shipped? This would involve everything from discussing with product people to nail down requirements, to breaking down tasks, to being the technical lead, etc. This area varies a lot from company to company. Some places have business analysts, scrum masters, or their team lead gets very involved with this part. So the exact requirements here depend on that. But there would be at least some work here for all seniors.
• people skills - mentoring junior members, influencing leadership to make good technical decisions, working with team members, and probably a bit across teams.
• being practical and customer focussed - making sure the work you do contributes to your company’s bottom line, balanced with the technical and people skills to make sure the company isn’t building up too much technical debt, and can sustain itself long term.

In other roles, senior might also involve mentoring others - there's an endless list of things that can be added.

A practical way to gauge seniority, although subjectively, can be to simply ask the people around you, if you are senior.

You can also read up online - for example this excellent talk which I have seen in person.

Despite people's best efforts to define all of this, the process to progression to senior is still quite a black box at most companies. It's not a secret to talk about the process, but it's certainly mysterious and secret-like.

In an industry such as software, the stereotype of a rock star ninja developer probably hinders defining what a good developer actually is. There are stories of places where people really had to really "prove themselves" to get to the next level of seniority. That sounds like a recipe for burn out.

Moreover, the people making decisions may not be experienced enough. Red flags for this include:

• being told that you should not care about titles, as it should not be your main pursuit in your career.
• being told that others haven't been promoted so the process is unclear.
• being told that apparently many people do not meet it their title once they achieve it - which sounds like an error on the part of management. This is all beginning to sound like an industry wide problem where two levels of engineer are simply not enough. Some places have more granular structures which seem more reasonable.
• if a role is not met, then apparently company "performance improvement plans" can have legal implications like an employee having to meet certain performance by a set date, to risk not being let go.

On a more positive note, to define "senior" you can reach out to the people team for guidance, but it should be your manager's job to know this.

In the absence of people knowing things, you can reach out to mentors, peers and contacts for their opinion.

If you aren't getting clear answers and are past the usual timeframe, then by process of elimination there are two options:

• something is extremely wrong with your performance, and you should have been told if this is the case
• or, the standards are unknown and/or possibly too high. If the standards are unknown, they should be made clear to you.

Or possibly a third option - that you are on your way for a title change. Since generally nobody will directly tell you that you are getting a promotion. Although at some companies this does happen.

From all of this analysis and reflection, all that can truly be said is that everything is subjective.

But that is a bit bleak. There is hope, if you have a decent team, to define various things, like for example via career matrices, or breakdowns like in this link, which are structured and detailed. Details should always be made clear, to make the process of acquiring experience less subjective, and more objective.