Provoked by going down a rabbit hole on using adjacent skills to foster career growth and career serendipity, I wondered what skills/disciplines would be considered adjacent to software development.
Writing, You need the ability to clearly communicate in code and within team. This get more important as you get promoted.<p>Inner peace (mental strength). You need to manage stress, bad code and broken business process. In most cases coding is mentally exhausting.<p>Ability to listen people. This cannot be overstated, It helps to align effort and value. You want to do things with the highest value with the least effort.<p>Introspection. You need to investigate your experiences and decisions to learn. It is about learning from own and others mistakes.<p>I would argue that from some point in your career coding is easy part. Other aspect get more important.
All of them.<p>Craftsmanship of most forms (think all the disciplines that intersect with you from mechanics to electrical to woodworking to concrete to have) directly impact your ability to think broadly about a project and have lots to teach.<p>Philosophy and political science and sociology and psychology give you insight in how to approach disagreements and nurture consensus on plans of action.<p>The liberal arts like art, history, or writing help relate things to others and help foster your ability to recognize beauty and elegance, which can help you identify where a solution is great or lacking.<p>Fashion, graphic design, animation, video editing, sound editing, etc. are easier to see the correlate, but design in everything will help you make better designs and push toward them.<p>Learning basically anything will help you get better insight into other topics by building up connections and scaffolding to make things more relatable and approachable to you. So learn everything, because everything you do is informed and supported by everything you know. This same advice applies to every aspect of life and every career.
This has just been from my experience but:<p>Prioritization: Most engineers find this difficult but identifying what needs to happen "now" and what can happen "then" is critical to being able to hit all of a company's targets. Being able to say "Yes, what you're talking about is important but we need to focus on XYZ to get to {Series A, Series B, Revenue Target, Milestone, etc}" and stick to it is very difficult to many people. I've heard "but this code is ugly" or "it's hard to support" but it's, most of the time, like complaining about the color we've decided to paint a boat while the boat is actively taking on water and sinking.<p>Business: Business is the language of managers, C-level, and the average non-technical employee. If you understand what your product is, why people pay for it, and how you can get people to pay more for it, you'll always have an understanding of what direction your company should be headed in. As an engineer you also have way more information about what is possible than everyone from the management team and if you can identify a quick win, hammer it out, and tell management about your idea and that it's already implemented they'll be blown away (most of the time).<p>Fostering Teamwork: The reality of the situation we find ourselves in is that pretty much anyone can code. Long gone are the days where an engineer needs to think about how much power/clocks/ram/disk an algorithm needs to take in business software settings. By and large even engineers at huge companies like Google just string together solutions by calling into functions/code written long before they started working there. This means that the real value to be delivered to a company is in making it so that these engineers can forever stay productive and that they never really need to understand the lower level tools to be effective. Program for your company for a day and you'll feed them for a day, teach everyone at your company how to program and you'll feed them for a lifetime. Find a way to position yourself as the guy people come to for help/tooling gaps/design questions and you will increase your value to the company. "X wants Y but they'll make our other investments worth (10*Y) so it's a no-brainier".<p>Make Failure Ok: No matter what you do you'll make a mistake at some point. What you need to do is add just the right amount of padding on everything so that no matter what mistake you make you land on soft ground. For instance, even if it's very over priced, I insist on backing up everything everywhere I work. Everyone thought it was a little much until recently one of our main QA DBs failed and we were able to recover. A few years ago that would have halted the dev process at the company for 3+ days which at a scale of more than 5 engineers is a massive loss. The moral is that if something CAN break or fail it WILL break or fail and plan for it to happen no matter how large or small your company/team is.<p>I've only recently started my career in SWE/SRE but these seem to be common patterns/practices that have worked for me.