I am trying to set up a career / development plan for myself towards becoming a senior developer. With senior, I am referring to a developer with a very attractive CV which will quickly get new projects as soon as the last one is approaching the end.
From my perspective, I assume skills can be divided into a few groups:
"Industrial development"
Focus on getting a better toolbox working with others: Being fluent in tools like GIT, Docker, Testdriven development and so forth
"A more complete toolbox"
Focus on pure Python-skills as well as Python libraries. Decent skills in databases, front-end languages such as React, as well as other tools many developers meet like Spark.
"Better customer focus"
A client want a person that understand their problems, can come up with solutions and make these solutions.
And of course just be better by writing more code.
I am not looking to specialise in any particular direction yet. What should be on my list of technologies or skills to learn for the next year to be able to become a more attractive developer? What are the minimums a solid developer should have in their tool-box to take the next step?
Thanks for any input
(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.”
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/
> 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.
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.
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.