3 ms·
Ask HN: Which direction to choose? How to grow to senior?
Hi HNers,
I am Middle Software Engineer doing Go Back-end stuff. I am stuck in my knowledge base, growing professionally. As Middle software engineer, who doesn't know which direction to choose, what do you suggest to dive deeper to be able to jump into Senior Software Engineer position (not just label in Resume, but to be an actual Senior).
If I say about my knowledge base:
* REST API - yes I know how they should work, but usually do not follow all the guidelines
* HTTP protocol - yes I know how it works, but constantly puzzled when I encounter CORS, CSRF and similar stuff.
* Databases - yes I know a lot about PostgreSQL, but I do not know how to optimize or denormalize data to make queries more performant, other than just adding indexes here and there.
* Web frameworks - yes I know, there are some of them, can add middlewares here and there, but I probably cannot write one from scratch
* TLS/SSL - yes I know how they work in general, but no deep knowledge
* Message Queues - yes I know how they work in general, but when to use Message queue vs RPC/REST calls, cannot distinguish
* .... - lots of things I can answer that yes I know how they work, but no real world high load/high scale production experience.
Please assist me, which direction should I go to grow professionally:
* Which direction is trending or popular now, so that I can select? (Cloud, Devops, Machine Learning, Hardware......)
* What should I read?
* What should I write?
* What should I do?
(Do we have senior engineers? sure, but usually they do their job and do not talk too much, do not answer to questions too much, just silent geniuses)
- itamarst 9y agoJunior/Middle/Senior is vague terminology, but I'll take it to mean "does what is told", "can work a little independently", "can work completely independently". Being a senior engineer is often not about understanding the technology deeper, it's about other skills. For example, a senior engineer wouldn't need to ask which technologies to learn, because they would be able to figure it out on their own. A senior engineer would just learn these technologies when it's necessary. At the core is ability to work towards goals: rather than someone saying "do this" and you do what you're told, you're able to figure out solutions on your own, and even more so identify problems on your own, and then work out a solution. Knowing a "trending" or "popular" technology won't make you a senior engineer. What you do need is ability to solve and identify problems better. I talk about this in more depth in context of productivity here: https://codewithoutrules.com/2017/10/04/technical-skills-productive/ https://codewithoutrules.com/2017/10/04/technical-skills-pro...
- thrway0204 9y ago> you're able to figure out solutions on your own, and even more so identify problems on your own, and then work out a solution. How do I obtain these skills? As I told, I am stuck in this loop, tell me what to do, I will research and do it, but when it comes to architectural designs, I cannot select them, I know little about their trade-offs, can research more, but damn it, I cannot decide final solution to select (probably because of lack of enough experience)
- itamarst 9y agoThis is a better articulation of where you feel stuck, so that's helpful. A lot of design decisions come down to pattern matching: you learn how to recognize certain patterns and that helps you decide (I recommend reading some of Gary Klein's books, e.g. "Power of Intuition"). So you need to expand patterns you can match. Some ideas: 1. Read case studies, e.g. http://www.aosabook.org/en/index.html http://www.aosabook.org/en/index.html. But ideally case studies tied to specific problems you're facing at work, rather than generically. A case study is specifically "here's what we built and why", which is more useful for pattern matching than "here's a tool you can do some stuff with". 2. Get your experienced colleagues to explain their thinking. Since they're mostly pattern matching, they can't necessarily offhand explain why they chose something, so maybe try to force them to think more explicitly. E.g. ask questions like "here's a hypothetical different approach, why wouldn't you go with that" and see if they can articulate that beyond "it's wrong" - how is it wrong? 3. Switch to job where you can learn more. 4. Build prototypes, see how they fail. 5. Get your colleagues to tell stories about failures and successes.
- godelmachine 9y agoThe Architecture of Open Source Applications is a very good book series! If ever I get bored of reading the chapters, I immediately skip to "Lessons Learnt" section which usually comes at the end.