
Ask HN: Which direction to choose? How to grow to senior? - thrway0204
Hi HNers,<p>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&#x27;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).<p>If I say about my knowledge base: 
* REST API - yes I know how they should work, but usually do not follow all the guidelines<p>* HTTP protocol - yes I know how it works, but constantly puzzled when I encounter CORS, CSRF and similar stuff.<p>* 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.<p>* Web frameworks - yes I know, there are some of them, can add middlewares here and there, but I probably cannot write one from scratch<p>* TLS&#x2F;SSL - yes I know how they work in general, but no deep knowledge<p>* Message Queues - yes I know how they work in general, but when to use Message queue vs RPC&#x2F;REST calls, cannot distinguish<p>* .... - lots of things I can answer that yes I know how they work, but no real world high load&#x2F;high scale production experience.<p>Please assist me, which direction should I go to grow professionally:<p>* Which direction is trending or popular now, so that I can select? (Cloud, Devops, Machine Learning, Hardware......)<p>* What should I read?<p>* What should I write?<p>* What should I do?<p>(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
Junior/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-
pro...](https://codewithoutrules.com/2017/10/04/technical-skills-productive/)

~~~
thrway0204
> 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
This 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
The 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.

