I’ve been working in software development for more than 7 years. In that time I’ve worked at 2 companies, on very different kinds of projects and tasks.
My first company was in the fintech sector, building applications for finance companies. My current one builds infrastructure software: open-source web application frameworks (ABP Framework, ASP.NET Zero and ASP.NET Boilerplate), libraries, modules and the tooling around them.
Across all those years I’ve learned a lot, both from the projects themselves and from my team leaders and colleagues. I took notes along the way: the small niches that seperate a junior dev from a senior one, better planning and judgment on tasks, prioritization, project management, writing better software, talking to customers, giving trainings and consultancy and so on…
Like almost every engineer who had just graduated back then, becoming a Mid and then a Senior Software Engineer (as soon as possible) felt like the thing that mattered. It was a career goal but also personal satisfaction. Also, a way to earn real judgment over the projects and teams I was part of.
In the AI era, titles become less important (or seems that way to me), at least in the sense of “naming” them. But in my opinion, the small nuances behind those titles still matter and maybe more than ever!
So, I want to share what I think means to become more “senior” at what you do, focused on my own area of interest: Software Development and Engineering.
Everything in this post comes from my personal observations: the (successful) senior software engineers I’ve worked with directly and the well-known software figures I follow and read.
I’m writing from a software engineering perspective in general, but I think almost all of it applies to anything you do. If you have something to add or you disagree with any item, please don’t hesitate to comment. I’ll read and reply to every single one, thanks in advance!
One of the first things I noticed about the senior engineers around me is at the end of every day, they had something finished. Not “I made progress on it.”. Something done!
Note: “Finished” does not have to mean shipped. It means one piece is completed, verified and/or you’d be comfortable if a teammate opened it tomorrow without asking you anything. Others should be able to see an output from what you have worked on yesterday, it can be an ugly UI, incomplete backend control and checks, but something currently working and ready for the next stage!
I used to think this was just discipline but it isn’t. When you close the day with a finished piece, two things happen:
First, you get the motivation that comes with actually completing something.
Second, and more importantly, you now know exactly what’s left and passed the hard part, which is “starting”.
When a day ends with everything half-finished, you can't plan anything. You don't know how much is left. You just have a vague sense that the feature is "mostly there", and that sense is almost always wrong. Also, I believe finishing something every single day have positive impact on your own motivation and allow you lean on things with better judgment.
This is the habit that changed my daily work the most in the AI era. You need something to run and verify and then continue with the next thing ahead of you!
→ The loop I try to follow: get to a first result, bring it to a state where I can check, test, and verify it, then move forward. Then repeat until your task is done.
If I'm working on a large feature during the day, I want a few of its small pieces to be complete and testable by the time I stop. Small slices, each one verifiable on its own, then progress from there (this also provide a great feeling of progress and satisfaction I can’t fully express).
With AI in the loop this becomes critical. When an agent generates a large amount of code at once and you haven't verified anything along the way, you end up staring at a huge diff with no idea which part of it is actually correct. You lose the thread completely and probably just commit the changes and manually test if it works as you expected. And in my experience, the time you "saved" by generating everything in one shot comes straight back during debugging, usually with interest.
So, the rule is simple and more logical: small slice → verify → next slice (it sounds slower, but it’s definetly not!)
This one took me the longest to accept, because it feels backwards if you come from a backend background (I do).
When you build a feature, the right move is often to start from the front: the design, the screen, the basic flow the user will go through.
See it working first. Then, step by step, dress it with the backend, the architecture, and the real data. This way you can finish tasks easier and earlier then before.
For example, let’s assume that you’re building a stock control application. The instinct is to start with entity design, relationships, the database schema, maybe the repository layer. That feels like the serious way to work and as you may notice, while you are building with this mindset, you have a long way to go to see the actual product/feature visually and shape along to way.
But you can (and should) also go the other way. Build the screen the user will actually see, with dummy data. Get the flow right. Let the people who asked for the feature look at it and tell you what’s wrong (or provide you feedbacks), because they will, and it’s much cheaper to hear it now than after the schema is in place.
Then, later in the day, you pull that dummy data over to real data, and you get into the entity design, the architectural decisions, and the optimizations with a much better understanding of what the feature actually needs to be.
Also, note that, this suggestion pairs well with the first two: When you go with something visually, you increase your changes to left the day with something working, verifiable and ready for next stage for day 2!
Here’s where I think the real shift is happening.
AI writes most of the code now, (almost) all of it. The part of the job that used to fill the day (typing the implementation) has shrunk. What’s left is the part that was always harder (and more important) anyway: owning the thing.
Ownership, the way I’ve seen good senior engineers practice it, looks like this. While you work on a feature, ideas accumulate. Not only technical ones. Edge cases you noticed, improvements you’d make later, a documentation gap, a marketing angle, a follow-up feature that only makes sense once this one exists.
→ And those ideas don’t stay in your head. They go into a backlog list. (it can be a plain .md/.txt file, word document that your team also can see, or directly an issue in GitHub — the important thing is that the ideas live somewhere other than your limited memory!)
When I work on something properly, by the time I'm done I usually have enough collected ideas around that single feature to fill months of follow-up work. Technical items, product items, content and marketing items, questions to ask the customer. That accumulation is the signal that you were actually engaged with the problem instead of closing a ticket.
I believe documentation is not a side task that comes after the feature you built. It’s a step of the feature. In most cases I treat the work as unfinished until the docs are written. (and in my experience, if you approach it otherwise, the documentation task will wait for really long to be completed and it’s effect that started to be seen by your customers/users)
Sad but true, but if the customer, or another developer on the team, doesn't know the feature exists, or doesn't know what to do when they need to use it, then that feature was built for nothing! You spent the time, you wrote the code, you shipped it, and it delivers zero value because nobody can find it or use it.
That’s a harsh way to put it, but I’ve watched it happen more than once. Good features nobody used, because nobody knew they were there.
→ Writing the docs alongside the feature also helps you to expose the bad design: When you can’t explain how to use something in a few clear sentences, the API is usually the problem, not your writing. That’s a signal worth catching before the feature ships, not after.
While I was collecting notes for this post, I came across a LinkedIn post from Addy Osmani about career advice for software engineers in the AI agent era, and it lined up with a lot of what I'd already written down. It's worth reading in full:
A few of his points connect directly to what I described above:
Find problems, don’t just solve them. His argument is that agents are making problem-solving cheap, which makes choosing the right problem the scarce skill. Even if an agent could implement your entire backlog, that doesn’t mean all of it should ship or implemented at all.
Shift from doing to directing. Scope the task, define what “done” actually means, calibrate how much you trust the agent, then verify the result. Defining “done” upfront is the same verify loop I described earlier, just stated from the delegation side.
Sprint the last mile. Agents hand you the first 70-80% of a feature quickly. The remaining part (quality, edge cases, refining the architecture, the polish) is the actual work.
Own what you ship. “The AI did it” is not a defense when production breaks. Your name is on the change and you own what is shipped, so you should act responsibly!
That’s the same thing the senior engineers I worked with were doing years before agents existed. The tools changed but the behavior didn’t. So, following these rules are still extremely important!
That’s the whole list:
Finish something every day.
Keep the work in a state you can verify.
Start from what the user sees.
Let the ideas pile up and take responsibility for them.
Write the docs as part of the feature.
Titles matter less now, and I think that’s genuinely true. But the habits behind them are the part AI hasn’t touched at all. If anything, the code becoming cheap makes the judgment around it more visible (and more important), not less.
If you have something to add to this list, or you’d argue against one of the items, leave a comment. I’ll read and reply to every single one.
Thanks for reading, see you in the next one :)
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.