Important non-programming skills for programmers | Hacker News Reader

Important non-programming skills for programmers

welearncode.com

91 pointsIncRnd70 comments

Writing documentation for your code/library/framework/project should be another one of these skills. I have written a lot of documentation for a project [1] recently, and it has made me realize the importance of this skill. It is often overlooked by programmers, myself included, as before this project, I never wrote proper documentation.

Sure, you can get technical writers to do it for you if you have a big team, but a lot of small, open source projects suffer from the lack of proper documentation.

[1] https://www.gethalfmoon.com/docs/introduction/

I agree. Out of curiosity, what was this project?

I edited the parent comment with a link to the docs.

Halfmoon look real nice, as does the documentation. Kudos

on a similar note I've always been shocked by linux distros wikis. you can have:

- near nothing, good luck

- debian, ultra structured, .. hard to digest / boring

- gentoo / arch, barely structured, just enough content to get the gist, yet precise, and a lot more tips for funsies.

this is an art

fwiw I find the arch approach the best tradeoff of practical and useful. Usually when I go to a distro wiki, I'm not really going there to learn in-depth what it is. I'm going there because I have a problem or a question. So having low-structure (easy to contribute to), high-signal (too much low-interest clutter info tends to contribute to documentation decay) tidbits seems to work out well.

I particularly like that if I have an issue, and I figure it out, I can just pop a quick line in there. h4:"Issues snafucating while running nvidia proprietary driver". Body: "you get this error message. <snip>. This is due to <snip>. Run this command to fix it." And it's already at the quality that people expect.

Yes and this tells a few things about what a good piece of software is. Arch is not easy but it doesn't bloat you, it gives you a few pieces to play, when you have an issue there's a paragraph for you.

Software is often documented as if it was a integral part of the program, but it's wrong on the human level I believe.

Even though I have never use Arch, the most helpful texts are always comes from and intended to Arch. That tells something.

Good documentation is hard but, in the current jargon, it is a value multiplier — or rather, poor or missing documentation is a value multiplier with a factor ≪1.

Good documentation also needs ‘testing’ by someone who is not already familiar with the content.

I was hoping one of these would cover personal care and hygiene.

It seems that taking care of oneself is a problem for at least one person on every team. Either they don't regularly bathe, wash their clothes, or they smell (either due to smoking, drinking, or body odor).

In my experience half of these people are suffering from mental health problems such as depression.

What sort of ratio do you think you have experienced of one group to another? I have never encountered anyone like that here in Australia during my time as a dev. It must be <5% of people surely?

Maybe I am nitpicking, but which of these skills would not be relevant for a non-programmer? Or for that matter, which of these skills would not matter or be important to a regular, non-coding person in general?

They are definitely good general human skills. The article highlights the relevance in programming because it’s easy to assume that strong technical skills are enough and that this baseline “dealing with humans and solving problems” toolset is not needed as much. Whereas “the job” you have as a programmer requires these baseline transferable skills in order for you to be effective, even if you’re super good at whatever technical skillset.

Agreed. It is easy to forget the human elements of your job. More so when you are very technically focussed.

I want to see "The Most Important Programming Skills for Non-Programmers"

If I made a list the first skill would be 'Explaining the bug you're seeing without saying "It just doesn't work."'

0. What was your goal?

1. What did you do? (Report the steps exactly.)

2. What did you expect?

3. What happened instead? (Report the messages exactly.)

4. What are your wild speculations about the causes and solutions?

Documentation reading comprehension.

The most important "programming" skill for non-programmers is simply knowing when a programmer could automate some tedious, error-prone task that the non-programmer spends a lot of time doing.

I remember when I worked second-level support. Most of us had no programming ability. I did. A coworker used to spend hours—when he had many other things he should have been doing—on some ridiculous task that a bit of text processing could have automated. When I found that out, I wrote him a script and told him, "Be on the lookout for things like this. Don't ever waste your time with something like this again. Ask someone who knows how to program if there is something that could be done."

I'm guessing there is a lot of that out there.

6.0001 [0]

Seriously. One simple intro to CS class will allow a non-programmer to more easily differentiate between what can be done easily and what can't [1].

[0] https://ocw.mit.edu/courses/electrical-engineering-and-compu... [1] https://xkcd.com/1425/

The xkcd didn't age well, unfortunately

Microsoft Excel

That would be: "First, turn it off and then back on."

1. Knowing when to be lazy

On a similar topic of programmers needing to know non-programming skills, I'd suggest the book, "How To Be A Programmer"[1] by Robert Read. I read it about five years ago, and I liked it.

Talks about the essential technical skills -- managerial skills to manage a team of programmers, ethics of working as a programmer, and being part of a team. I remember loving the topics on how to talk to non-programmers and deal with difficult people.

1. https://www.amazon.com/How-Be-Programmer-Robert-Read-ebook/d...

I loved reading through this even as someone with a chunk of years in the industry. It puts pen to paper on a lot of topics that we usually deem "obvious".

You can read it for free online here: https://github.com/braydie/HowToBeAProgrammer

One thing that this book mentions (and which many people swear by) is "self documenting code".

In my experience, I've found that:

(1) good "self documenting code" is typically written by programmers who care enough about documentation to write at least a high-level description of what their code is trying to achieve, what problems it is trying to solve.

(2) programmers who swear by "self documenting code" usually write code that is anything but self-documenting. Their output is usually so gloriously complex that nobody apart from them can easily read and understand their code.

Based on the people I've seen during my career: The skill to stop procrastinating and start programming. Being able to pick up tasks reliably is way more important than technical bravado.

> Being able to pick up tasks reliably

Based on the people I met, this usually comes with a great talent in completing tasks within the imposed delay, by putting in the least amount of effort as possible (especially with regards to understand the task), providing a solution that is only acceptable at a very shallow level, and forgetting everything about it as soon as possible.

Basically, the developers who are most appreciated by box thicking managers are usually the culprits of overall project slowness or plain failure.

In my career the thing I was hurting most from missing the first decade was negotiation skills. Learning a few simple ones has changed my life.

An excellent book on the subject is Getting to Yes: Negotiating Agreement Without Giving In

Had specific advice with examples. I think it's been helping me all my life. It is based on the work of the Harvard Negotiation Project.

https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit...

Negotiating is huge. There are likely several ways to achieve a feature's goal. As a programmer you have to negotiate the solution with the customer or product owner and even the rest of your team. It allows you to pursue solutions that can save time and result in better architecture. Be sure to ask and understand why a feature is needed. Knowing the why let's you shape the what.

"Be likable" is the most important skill. Everywhere.

As my college professor told me many years ago, "people do business with you because they LIKE you more than any other reason. Continue being likeable and you will be successful."

I will say that this is true more for entrepreneurs that for Corporate America. I had many successful years as an independent consultant where being likeable was more profitable than being most other things. But I learned when I took the corporate job that it really seems like assholes get ahead more than anyone else. Or as I say, "the biggest bully wins." (Unfortunately, I am not a very good bully.)

Strongly agree with empathy at number one.

After years in consulting I would say most project failures I see are failures of empathy.

>most project failures I see are failures of empathy

That is quite the statement. Would you provide some examples of situations that made you come to this conclusion?

Lack of empathy toward user/client made him replace us. Real story.

Lack of empathy toward programmers led to imppssible schedule. Real story.

Lack of empathy between team members who were supposed to lead cause spectacular dysfunction of team I am in right now.

Very few software projects in my experience fail because they were too technically difficult and/or that the people involved were incapable of working through some technical problem.

When I say failures of empathy, I'm not even saying that that was the failure of a single person to empathize, but that at the end of the day the collective parties could not understand enough about what all the other parties needed to create an actionable plan and put the people in places to do it.

This can be:

A software developer failing to empathize with someone in the c suite and understanding the direction the project needed to go in to be considered a successful project

The c suite failing to empathize with the development team in terms of understanding what skills and abilities they are offering and what resources and direction needed to be given to them to properly convey their goals

Failures of the dev team or executives to empathize with their users in order to create a thing that is actually wanted in a way that will actually be used.

Failures of technical teams to empathize with budgetary and business concerns and the reverse.

All sorts of other failures between people in the middle to empathize in terms of being able to understand priorities and goals and allocate energy accordingly and understand the hierarchy among those goals.

Failures within a dev team to empathize with each other leading to all sorts of various breakdowns.

People are generally not very good at mapping out complex webs of incentives and goals and the ability to empathize is what underlies that in my opinion.

I've sat in on an absurd number of projects where whatever silly stuff they thought was their roadblock was so far away from what was meaningful to the higher level goals of the project that they were absolutely doomed from the start. You can have projects like that go on for years in enterprises where they never even get on a viable path to creating anything productive. It generally ends up as some sort of battleground for internal politics in that case.

At the end of the day, the ability to think in terms of hierarchical goals and incentives and escape the concerns of your personal silo is a majority of the time what could avoid this in my opinion.

Since this is in huge part about ethics, not skills as such, there was a related submission recently: the ACM Code of Ethics and Professional Conduct. It didn't gain much traction (perhaps it was discussed earlier) but the document is very comprehensive and well worth reading through: https://www.acm.org/code-of-ethics

Link to HN submission: https://news.ycombinator.com/item?id=24533181

I'd add two more:

- estimates: ability to balance between showing off when estimating the skills and technologies you know well and then underestimating the process ahead and overestimating the unfamiliar territories.

- fast typing: I could never relate to developers as senior, no matter the years of experience, if I see them shooting the keyboard with two or four fingers. Despite my subjective position on this, fast typing "releases" your brain to think only about the problem you're solving or achieving the goal you have without dialing 911 to "find that letter".

EDIT: I've used a wrong phrase in my second point. I meant "touch typing" instead of "fast typing".

Early in my career, I also thought fast typing was important. Then I worked with a severely disabled engineer, who could manage to type at probably 3 words per minute. Even at this snail’s pace, he could produce as much as anyone else on the team, and his work was of a higher quality.

Are you sure he produced as much in the same amount of time and didn’t work longer outside of office hours?

No judgement, I also have a disability that only allows me to type with one hand.

> Are you sure he produced as much in the same amount of time and didn’t work longer outside of office hours?

I wonder if due to reduced typing speed the developer in question had a higher ratio of kept code to deleted code.

Someone only able to type 3 words per minute may have developed patterns of thought and deliberation that maximize those 3 words rather than follow development habits of faster typists that might be prone to generate code which never sees the light of day.

I type quickly and have no qualms about deleting entire stanzas of code and rewriting them when things don't work out. If I could only type 3 words per minute, my approach to writing code would radically change, perhaps for the better.

I have seen this in practice multiple times.

A ‘prolific’ codewriter, writing a ton of code, most of which is thrown away.

Would we assume a novelist that types faster writes better stories?

Back then, we didn’t have remote access. Had desktops instead of laptops, and I saw him arrive every morning and leave every night. I’m not saying the rest of the team was immensely productive, but he kept up.

I had a 70 years old team member whose typing wasn't fast at all, due to various age related issues, but was one of the most valued team members. Case like that, or people with disabilities are obviously out of any judgement.

Great, if I don't have an approved impairment that meets your standards I'd better type 200 WPM.

(I type around 110 WPM, but I have no frame of reference for whether this is "good". Who cares?)

Not sure if you've seen my edit in the original comment: "fast typing" was a wrong choice of words. I meant "touch typing".

Why type when you can copy and paste?

I always type everything out the first time I’m introducing something into a code base even if I’m taking something straight from the docs or Stack Overflow that solves an issue I’m dealing with.

It helps me understand how the data is flowing through whatever it is I’m doing, the structure of the code, and ensures I don’t leave in extraneous unnecessary flags and options.

And I’ve always done this, I much prefer engineers who work slowly and methodically, understanding what they’re doing.

It more than makes up for the “lost time” when you need to debug a complex system that’s on fire and people don’t even understand what the options and flags they’ve pasted in actually do.

If you saw many seniors with slow typing speed, wouldn't that be a sign that typing speeds doesn't mater that much?

Not many, but when I did, I've considered it as something I'd try to find out - why. The benefits are obvious, learning process is rather easy so reluctance to do it would at least intrigue me.

I have to disagree with the fast typist - depending on your definition of fast. Without any formal training, I touch type with one hand (not by choice) and I am decently fast and accurate. But I spend much more time thinking than I do typing.

But on the other hand, I can’t imagine having two good hands, be a professiomal software developer and not learning how to touch type. It just would seem to be a level of laziness.

I thought I explained it in the original comment... I have no issue with the speed of someone's typing. But constant checking of the key positions on the keyboard just affects your focus on the problem you're working on. And it's really fairly easy to learn to type without looking, to type without having to think about it.

“Touch typing” just kind of happened organically with me. I’ve been programming since the mid 80s in middle school. After awhile, your fingers just kind of know what to do.

I wrote the wrong phrase in my original comment. I was thinking of "touch typing", not "fast typing". Thanks for helping me clarify that - not a native English speaker here.

Btw, I've learned it almost the same way, but while playing the typing games with my kids later in life, I've upgraded the skill a bit.

> "fast typing: I could never relate to developers as senior, no matter the years of experience, if I see them shooting the keyboard with two or four fingers"

One of my very good friends and one of the best programmers I know types slowly and using only four fingers and a thumb. He's paralyzed in one arm.

He's still been an absolutely prolific open source contributor and 2x YC startup CTO. Typing speed probably isn't as important as you might think.

I see a lot of these that basically say the same thing.

I think someone should write a blog post about the non-programming skills you need to be a staff/principal engineer.

And the ability to sell themselves.

Anyone got a good read on how can one sell oneself?

https://news.ycombinator.com/item?id=24582151

Just posted!

Not a single mention of the word requirements.

Software developers generally have two jobs: to figure out what to make, and to make it. They have to build the right thing, and to build the thing right.

I don't put much stock in an article like this that doesn't even mention requirements engineering.

Whether this is part of your job probably depends on how your team is structured. I have yet to be on a team where the part about building the right thing was the engineer's role. There was a product owner or project manager for those decisions.

There's two sides to requirements. There's the functional "what is required to fulfil the user's need?" part which is very much in the product owner's domain, but there's also the non-functional requirements like "The feature must not compromise security" and "Performance metrics can't fall below X". Those parts are defined by the engineering team.

Building the right thing is product, building it the right way is engineering, and they both feed in to defining the requirements for a feature.

It seems to me like you basically need a programmer who has experience doing the actual job to specify what's needed.

I've seen things get morphed from what the users need to what management wants and end up badly misaligned.

You're also right that there's a gulf between what users ask for and what can be sensibly implemented due to security, etc. considerations. E.G. wanting SSL to just work and ignore all cert changes magically just isn't ever going to be secure.

You can, and should, write requirements and in more general all kind of specifications / high level pictures / architecture diagrams, for when you won't be around anymore, or even just for your future self.

Maybe even more for your future self than for when you won't be around anymore, given that will impact you if you don't even if you are selfish, whereas you could just quit and not care anymore about remaining or new people. Of course you should not be selfish, but even if you are, write requirements.

Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? I can't think about anything else.

In fact the article is so generic it could fit any job. It basically says: be a well rounded person.

> Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering?

Actually gathering and maintaining the fucking requirements in a useful way.

This is funny because it is true :D

i don't put much stock in a comment that dismisses the article out of hand on an arbitrary requirement. ironic.

Probably because requirements engineering is a farce. I don't think I've ever worked with a set of requirements that wasn't ludicrously out of touch with actual engineering and prompted all the engineers to essentially ignore any requirements given to them, outside of very high level ones.

Reply on news.ycombinator.com