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.”
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.
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.
Dead Comment
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.
Dead Comment