Ask HN: What skills are adjacent to software development? 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. |
Inner peace (mental strength). You need to manage stress, bad code and broken business process. In most cases coding is mentally exhausting.
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.
Introspection. You need to investigate your experiences and decisions to learn. It is about learning from own and others mistakes.
I would argue that from some point in your career coding is easy part. Other aspect get more important.
I have the opposite experience. Every thing in software development other than the coding is mentally exhausting.
When I'm all-in writing code time stands still, it's just brilliant.
Most senior devs I've been downstream from throughout my career write extremely carelessly. Their email, code comments, and docs (if they ever write them) are often borderline incoherent. It is the interns and junior devs who carefully "craft" emails and tenderly compose comments to remove any hint of ambiguity.
Once you're so senior that your company relies on you to announce new tech to a broad audience, you will almost certainly get the help of a technical writer.
Taking time to write well is a waste and an affectation, and it carries the stigma of insecurity. One should avoid it.
That sounds bizarre. Good writing is a skill, and the opposition to it sounds similar to anti-intellectualism.
I think a lot of coding is about writing for the computer and your future self/team. You want to favor simple and easy to understand. For non-native speaker is not obvious when to use remove vs delete. For me writing/language skill is a problem.
A common pattern I have observed is that developers most challenged at writing tend to be the developers most challenged at providing an original code solution.
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.
Philosophy and political science and sociology and psychology give you insight in how to approach disagreements and nurture consensus on plans of action.
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.
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.
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.
If you are doing interesting work it is important to run good experiments. Bad or ineffective experiments can be a huge time sink.
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.
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).
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".
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.
I've only recently started my career in SWE/SRE but these seem to be common patterns/practices that have worked for me.
Since I misread your message it was your fault for not communicating it clearly.
If you wrote something like this:
Most seniors I worked with had poor writing skills. They were failing to communicate because of lack interest in effective communication.