Ask HN: How to Become a “Senior” Developer

Go out and buy/find/read the following books:

(1) Patterns of Enterprise Software Architecture https://www.oreilly.com/library/view/patterns-of-enterprise/...

WHY: What kind of things do we need to build enterprise software applications, and where should we draw lines to separate concerns for these subsystems?

(2) Gang of Four Objected oriented design patterns https://www.digitalocean.com/community/tutorials/gangs-of-fo...

WHY: what are the recurring themes in doing good OOP as described by the guys who have been doing it since the beginning?

(3) Microservice Design Patterns https://microservices.io/patterns/microservices.html

WHY: What are the recurring patterns, themes, and challenges in building good micro service architectures?

(4) Uncle Bob’s Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

WHY: Write code that somebody else could pick up, read, and not be completely baffled by. In all likelihood, the next person to read your code will be you. Here’s how to do it.

(5) SOLID Design patterns

WHY: Essentially how to do good OOP part deux.

These are basically, in my opinion, the equivalent of University Physics or Eisberg/Resnick QM textbooks. They’re seminal texts with a lot of valuable insights into patterns, jargon that other seniors throw around, etc. Also depending on your learning style I’ve seen this material covered in a billion different shapes: YouTube pseudo-lectures, GitHub repos, blog posts.

Additionally, if I understand correctly you’re lonewolfing it? You mention “writing more code” as a solution, but the infinitely better solution to becoming a senior is “reading more code.”

Thanks a lot for this. I will look into it. And great suggestion to "read more code"

I am working for a consultancy, which does most of the selling. But as much of the selling is done by presenting good candidates, I need to be seen as a solid consultant in my own right. If my resume is not good enough, the clients will never want to talk to me, and I am very hard to place. E.g. I am passed for all the interesting work.

Most of the consulting assignments are companies that need another developer on their existing teams, which usually are consisting of two to five other persons or some smaller tasks which I am expected to solve for the client by myself.

Pick an ambitious side project(s), something that interests you and would force you to develop the skills you mentioned earlier. Work on this side project on GitHub, and then add it to your resume/portfolio, and make the code public. FWIW, if I were a hiring manager I’d be interested in the physics doctorate because of overlaps in systems thinking.

Not bashing your answer but I just want to say a junior-ish developer who has read some of those books and is now overconfident in their skills is one of the worst and most toxic combinations I have ever had to deal with.

Knowing very little yet too arrogant to learn and always ready to smack you with the appeal to authority of the last book they just read on 47 principles of good code.

So word of advice to OP, don't become the beginner expert who has crammed a few books and now wants to fight everybody for the best programmer championship belt.

Stay humble and learn from the master craftsmen who have been going at it for decades. No amount of Uncle Famous books and blog posts is going to substitute for that experience.

Agree

Then again, the reason it’s toxic is because of how we put rockstars on pedestals and perpetuate company cultures where plateaus are grounds for PIPs and terminations. Sometimes finding a mentor is hard when you feel like your coworkers and superiors resent your employment as a result of a supply-side shortage of “betters” engineers.

A senior developer in my book is someone with both leadership skills and the experience to back that up. Most of your work is enabling other developers with a bit of actual dev work sprinkled in.

You're still chiefly a problem solver like any dev, but your problems now are more than code. Hence, your toolset expands to implementing new processes, talking with non-devs, creating PoCs, teaching, and more.

Here's a roadmap I made to help out: https://github.com/glennsantos/senior-developer-roadmap/

> "Better customer focus"

> A client want a person that understand their problems, can come up with solutions and make these solutions.

Top of the list for me. That would summarise what I wanted from a senior developer. All the rest is nice to have.

I think the best way is to work at a growing company and show leadership and growth potential. Start completing projects on time and you'll probably get promoted or tasked with additional sr level responsibilities.

If you don't get promoted, you at least have some talking points when leaving at your next interview which can place you in that seniority bracket.

Stay employed for 2-3 more years

You need to learn how to communicate with other developers and understand their ideas and arguments. Same goes for customers, and management. Therefore my suggestion is to invest time in building up a good working vocabulary of technical and organisational skills. Take the time to mentor others even on small things, it forces clarity of thought and being able to speak about a topic. I have known absolutely amazing developers who can't talk or explain their decision making process, and it handycaps them since they can't expand their skillset past churning out code. As someone who has changed fields a few times, rebuilding my vocational vocabulary has always been the most time consuming and difficult part.

Here are some things I think are helpful for long term growth (YMMV):

- "The Mythical Man Month" by Fred Brooks is a classic for a reason.

- Learn how your tooling works to a reasonable level. It's worth investing time into tooling as you use it every day.

- For your long term technical development dabble with other languages and libraries, try to understand why and how they do things differently.

- Ignore orthodoxy, but educate yourself on why developers follow it and come to your own conclusions as to whether you agree or not. This means reading widely but sceptically, check out many different open source projects.

- A lot of what constitutes current industry best practice is not written for any one developer/organisation and the chances are it won't apply to you. There are organisations of all sizes dealing with problems of all different types and the current language/framework/library/infrastructure pattern of the month may or may not have been developed with you and your organisation in mind. Don't be taken in just because everyone's talking about it.

- Set aside object orientation and type systems for a moment and learn the language of data. Data structures and operations on them, normalisation & the relational model and how to model a problem domain as data are all more important than class diagrams or arguing about whether composition is better than inheritance. Once you understand and can navigate how data works, you can apply those rules to any programming paradigm you want.

- You need to know how to operationalise your projects, or at least communicate effectively with people that do. Writing code and throwing it over a fence to QA or ops won't do.

- If you're building code that will be exposed to the internet, you need to understand application security. Check out OWASP.

- If you're not working in organisations where coding standards are cared about, consider moving on. On the other hand, beware holding too strong an opinion. If your tech lead doesn't follow Martin Fowler's, or Bob Martin's, or the GoF, or test-driven development, or whoever else you care to name, that doesn't mean they're "doing it wrong". Nearly all "rules" and "laws" in programming are just some person's opinion.