Ask HN: How can I grow my mindset and technical skill as senior engineer

[celurian92]

I saw a post in HN. (Falsehoods junior developers believe about becoming senior)https://news.ycombinator.com/item?id=39502515

So as a software engineer who was recently promoted to Senior and working on various technologies over 5 years mainly focusing in java, mysql and js in small to medium size local companies how can I grow my mind and technical skill to be a senior swe

[vegetablepotpie]

The biggest difference between junior and senior software engineers, in my opinion, are soft skills. If you have gotten promoted out of being a junior, you have shown that you know how to solve problems. As a senior, you need to know “what problems should be solved.” What flows from that are other soft skills, “knowing how to give estimates,” “managing and mentoring others,” “knowing what it takes to finish a project.”

[Msurrow → vegetablepotpie]

And knowing what problems should NOT be solved (by tech). Not everything needs a tech solution. There may be many reasons for something not needing a tech solution. The only way you’ll get to learn if a problem needs a tech solution is the use soft skills to talk to not-tech people (often “the business”). Note the not-tech people might think they need tech, or new tech, so you’ll have to figure out by talking to them what the correct thing to do is. I don’t know how many $$$ I’ve saved companies (as a developer or architect) by challenging them on _if_ they really need shiny new tech thing to solve their problems. Can it be done manually/using existing tools within acceptable time/effort? Can we simply accept not solving the problem? Can we wait with solving the problem?

The thing is, it’s always a tradeoff. If you choose to go do a tech solution to a problem, you are spending resources (people’s time, people’s energy, budget, enduser goodwill, your own focus and bandwidth, etc). And if you are spending resources solving a problem using tech, that did not need to be solved using tech, that means you have less resources to work on other problems that really do need tech solutions.

In general for the “mindset” part of your question I would say learn to figure out the tradeoffs in every decision you make yourself or decision you provide an opinion for. Everything is a tradeoff; doing A means not doing B. You always need to know what tradeoffs are for anything you do.

Edit: Also, always build the simplest possible solution that does not prevent you from improving on it later.

[al_borland → vegetablepotpie]

To add to this… the ability to explain what is being built and why in a way that your audience will understand. Don’t deep dive on technicals to executives, but rather focus on business value it will provide. But still have the ability to deep dive into the technicals with the audience that wants that, or when an executive might ask for it, and has the understand to hear it. Meeting people at their level is hugely important and it’s up to you to adapt your communication to fit who you’re talking to.

You can make the greatest thing in the world, but if you can’t explain it and tell people why they should care about it, it won’t matter. This often means setting your ego aside and ignoring some really cool stuff you’re proud of, because it will be lost on the audience you’re speaking to. It’s all about what they care about, not what you care about.

[austin-cheney]

If you really want to expand your horizons try to write an operating system. It does not have to be from the metal up or involve kernel authoring. It can be as an application in your current OS, or even something that works in a web browser.

Writing a new OS will force you to consider security handling, transmission limitations, performance, original usability problems, organization that scales in multiple directions, and so on.