13 ms·

The most important software dev skills aren’t technical

140 points by philk10 8y ago

bpyne 8y ago
The following are at least as important. - communication - compromise - curiosity
- saiya-jin 8y ago
  Communication is by far THE biggest issue in many projects. Especially with geeky introverty software dev types. Heck, my fiancee is a doctor and the amount of crap that happens in hospital just because people (other doctors/nurses/patients) don't communicate clearly, make tons of incorrect assumptions etc. is astonishing (and has direct consequence in quality and quantity of health care provided).
kharak 8y ago
"Attention to Detail" is my major weak point. I don't have it in coding. Give my a philosophical essay, a political discussion or an academic paper and I'll drown you in details, implications and references. Those come intuitively to me. Writing codes is completely different. I have to practice everything what others seem to do intuitively. I need checklists. I need to take notes. I need to review my task and codes several times. And still, I overlook the obvious and never spot the easiest implementation (even for trivial tasks like checking for empty Strings). All while it takes me a great deal of discipline to take care of the level of detail that is required. If someone here has/had the same problem, I'd like to hear their solutions.
- dwrodri 8y ago
  Just out of curiosity, is you background in web development and/or the C family of languages (i.e. C, C++, C#)? I mention these because they rely heavily on object-oriented and/or imperative programming paradigms. With C and C++, I still struggle often with striking a good balance between "writing a short solution that works well" and "writing code which is a joy for others to read". The former often relies on my technical knowledge and produces code that can be obscure to other readers, the latter often requires MUCH more concentration and attention to detail when writing. However, I have recently started experimenting with declarative and functional Programming. Coming from an imperative background has made "relearning" how to program quite difficult for me, but I've just started to see the "elegance" in higher level functional languages, such as OcaML and Haskell. Of course, functional languages are often MUCH better suited to different problems than OOP languages, but combining filters, reductions, maps and folds seems to activate the parts of my brain that are much more closely associated with the "classical logic" side of programming. I think you should check it out if you haven't already.
  - kharak 8y ago
    You're on to something. I started with database programming, so mostly declarative. That was a joy and I did't need much time to catch up with the senior developers. Afterwards, I switched my employer and started anew with Java. I was completely overwhelmed and struggle to this day. Last week, I learned a little bit about streams and how functional programming works in Java. To my surprise, that seemed quite easy to understand. I don't really know why OOP seems so much harder for me to do.
    - jayar95 8y ago
      If you like the functional aspects of Java, check out kotlin. It's quickly become my favorite programming languages because you get all the benefits of java's strongly typed OOP system with a lot of elegant functional features, and type inference!!
    - mrfredward 8y ago
      Honestly, I thinks it's because a lot of OOP is awkward and forced. When it was the craze, object orientation became an ends instead of a means, and so it taken past the point of being clean and useful. Why do c# and java require every function, including main, be in a class? Why do we need static classes, which are really just a namespace for functions? There's no benefit to the programmer, it only serves the "everything is an object" paradigm. Certain OOP patterns, like the visitor pattern, are really just hacks to make OOP work like functional. I use c# everyday at work and for the most part love it, but there are certain problem domains (anything with significant multithreading) where forced OOP thinking just makes everything harder than it needs to be.
      - james_s_tayler 8y ago
        Curious, can you explain how the visitor pattern is like functional programming? What is it analogous to in FP? It's not a pattern I have ever really wrapped my head around fully, but perhaps there is some structure in functional programming that if I view it through that lens it will make much more sense?
  - 8y ago
- addicted 8y ago
  I suffer from similar issues. Something that really works against me in the standard coding interviews. Some ways I try to mitigate some of those issues at work are: 1) Peer/senior code reviews. I try and get code reviews done by other folks. This helps with identifying something easy that I may be missing. Usually, once I already have a solution to a problem, I find it hard to revisit it without that solution overwhelming my approach, unless a bit of time has passed. Getting some fresh eyes to look at it helps. Also, explaining the solution to someone else often helps me identify issues with my solution during the process of explaining it to someone else itsel. 2) Practice and experience. I think for the most part intuition is simply the result of experience and practice. 3) Learning different programming paradigms. Something that has helped me more than anything else I think is learning programming languages that cover different paradigms. I’ve never coded anything useful in Haskell, but just the process of solving basic programming problems in Haskell, with its strong functional approach, helps me identify issues with the proceduaral/OOP code which I do write to solve useful problems. I think it allows me to approach each problem from multiple perspectives so even if I don’t have certain Haskell features available to me, it makes it easier to recognize that this may be an issue I need to address in my OOP code (for example, the Haskell compiler when pattern matching requires all possibilities to be addressed. Awareness of this fact means that anytime I’m writing conditionals checking the input I’m much more aware of the fact that I need to also handle the else condition, something that most non-functional programming languages don’t hsually require in their conditional constructs). 4) Related to #3m opting for better solutions wherever possible. I always try and opt for expressions over statements. I try to avoid state change as much as possible. I try and minimize side effects in functions, and try to constrain them in specific areas of code, etc. 5) Formal CS study. I don’t have a CS background, but studying formal CS in my free time has helped a lot. Getting better at data structures, algorithms, formal verification, etc, has helped develop my intuitions even if I don’t sctually use those data structures and formal verification methods in practice.
- voidhorse 8y ago
  I can speak to this issue as someone who comes from a formal background of philosophy and literature, but whose work involves a lot of programming (both reading and writing code) at this point. Foremost: practice. If you can read and write essays at a college level you've been practicing the craft for (likely) years. Most educated people in the US start engaging with letterforms as soon as kindergarten (!), and no later than 1st grade if not preschool. Contrarily, we don't start so early with the rules of logic nor programming constructs. Most folks don't start programming until much later, and even those who are precocious in this regard usually don't begin using "real" languages (in other words, not stuff like lego robotics or scratch) until they are ~13 or so (of course, there are plenty of exceptions). As with most skills, practice is invaluable. On a conceptual level, I found that making the jump from asking myself what does this code do to what does this code mean majorly beneficial. It may seem like a minuscule or pedantic semantic point, but it actually makes a world of difference. Just like essays, programs are expressing—they are saying something. If you shift from approaching programming from a goal oriented perspective to a communications perspective your code will probably improve immensely. I think this is the reason guys like Donald Knuth stress code readability and literate programming so heavily—at the end of the day, that's what's really important: communicating some idea—just like we do in plain old english. We simply have a broader audience (the latter part of which is very picky about what it understands). The notion of a proposition in logic doesn't do, it means. Programs are essentially a set of propositions which just so happen to have the side effect that they can make a device (a computer) do something when it interprets them. Just as linguistic commands ("go to the store") are "pure" and free of side effects in and of themselves—they only have effects under human interpretation. On a somewhat related note, I find stepping away from programming languages and starting with pen and paper is great. I think people tend to let programming languages get in the way of the real nature of what it is they're doing, which is solving problems in a structured manner, using mathematics and logic (algorithms and data structures). You don't need a programming language to do this, it's only a vehicle to express your solution. Just as you'd often start writing a formal paper by exploring your ideas in an outline or notes, or a couple of first drafts in which you hash things out, you can start "programming" by sketching ideas for solutions and better comprehending the problem at hand. This will ultimately help you write better code. I think a lot of self-taught devs, such as myself, miss this part early on as our entry point into the discipline is often through the languages and tends to kind of remain at the level of the languages we like unless we dig deeper into the underlying formalisms driving them. Too often people just go along with their first-pass understanding of a problem and begin reaching for the libraries, language constructs, etc. that they think they need. Someone with formal training, contrarily, has professors that can help them recognize the concepts behind the languages and connect up and distinguish the notion of a language as a mode of expression and programmatic problem solving as a practice irrespective of the selected language.
asaph 8y ago
> So many things have to go right just to get a software program to compile. That’s why attention to detail is so important... Even the sloppiest coders who work with no attention to detail still compile their code with ease. I get the author's larger point about attention to detail but I don't think compilation is an effective example to illustrate that point.
- bmj 8y ago
  Agreed. I generally see a lack of attention to detail with regard to things like linting, unit tests, and documentation. Our CI builds fail way too often due to the first two items, which can be easily done via a single build target on a developer's machine.
  - asaph 8y ago
    A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.
    - swsieber 8y ago
      And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff. And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.
      - SketchySeaBeast 8y ago
        > And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.
asaph 8y ago
Continuous learning is also critical for success.
stuxnet79 8y ago
While the traits mentioned in the article are useful (patience and attention to detail), these are traits that are selected against in most work environments. Writing software "The Right Way" TM takes time and time is usually something most engineers don't have in abundance.
nukeop 8y ago
This goes against Larry Wall's virtues of GREAT programmers: laziness, impatience, and hubris. Impatience stems from laziness and made me look at entire classes of problems in a different way than many of my peers. It is crucial to the character of a proper developer and its lack cannot be substituted for.
johnrob 8y ago
The challenge of details is best solved via rigorous definition of “done” (i.e. acceptance criteria). If you don’t have consensus for that, there are a million ways someone else can re-define the problem and thus expose “incorrect details”. Many orgs delay this consensus, making for plenty of post code review work, but I don’t think that’s necessary bad so long as you don’t let PR comments hurt your ego.
- deleted 8y ago
  [deleted]
jaabe 8y ago
I agree with the author on patience, but I wonder if you can become a software developer without it. Sure some people will have more than others, but learning how to make code work is a terrible, terrible process and I’m not sure you can go through it without massive amounts of patience. I have a side job as an examiner for Danish CS students, and a noticible difference between first years and final project students is how they tolerate the frustration of having code not work. If you can’t sit through hours of not knowing why something just doesn’t work, you probably find a different field.
- swsieber 8y ago
  I think you can have different types of patience. Patience with getting something to work could be very different from the patience to build something correctly, which could be different from the patience to deal with people... But I agree - you probably won't become a dev without having or learning some degree of patience.
  - jaabe 8y ago
    The thing about people is an excellent point. The ability to work in teams would be on my personal list, but the author seemed to direct it at patience with a technical focus.
  - dahdum 8y ago
    In most situations I'm a pretty impatient person, but coding never seems to try my patience. Getting into the flow and working the problem is what I enjoy doing.
  - mr_toad 8y ago
    Some people are far too patient to be great programmers. They are content with the daily drudge of slow, manual tasks, whereas a truly good programmer would become frustrated and desire to improve things. http://threevirtues.com http://threevirtues.com
- JustSomeNobody 8y ago
  > Sure some people will have more than others, but learning how to make code work is a terrible, terrible process and I’m not sure you can go through it without massive amounts of patience. I think this is more about being diligent than being patient. There are plenty (too many?) devs who will diligently try and figure out something but that have no patience when dealing with others.
linkmotif 8y ago
I'm not sure these aren't "technical" skills. Patience and attention to detail? In my experience that's part of the technical skill of programming.
- brootstrap 8y ago
  same thoughts here. I mean i appreciate the article and write up. My big skill is openness, communication, honesty. I have worked with many brilliant nerds who cant stay focused and literally contribute jack shit to major projects. They probably make the most $$ too. I dont care how good your program or app is. If you cant talk like a normal person, accept criticism, negotiate etc. You are going to suck. The best co-workers i have are able to combine both the CS tech knowledge with other skills like good estimation, honest and open communication, clear planning and execution etc. You can just tell in my opinion. Start workign with someone on a project for an hour and you can tell if they are a nerd without focus who spends weeks doing useless shit, or someone who will seriously contribute to your team and help get shit done.
rarspace01 8y ago
To be honest, after I started in software development 10 years ago, the most important skill is (good) communication. If you can't understand your stakeholders or express concerns the prettiest code won't help you. Obviously it will help, but only after figuring out the former.
Yuval_Halevi 8y ago
I pretty much agree with the author. I'm not a developer but I worked with many developers in the last 6 years. Some of them were great and some were not so friendly. -Respect for others - Being friendly - Give good energy to the people around you in the office - Learn how to work in a team Those are the things that when a good developer has, he becomes a game-changing part in a startup
- C1sc0cat 8y ago
  The attention to detail and not missing obvious gotchas is something that comes with age / experience.
JoeAltmaier 8y ago
Agreed; the single most important characteristic of an effective performer is Conscientiousness. Working at a task, measuring the result against a standard, working some more, until its actually really done. The absence of this causes havok: a task thought done will turn out not-done at the deadline and become an emergency. A feature not measured against all the requirements will fail in test or worse! in the field and cause customer angst and extra cost to everybody.
- duxup 8y ago
  Does this make sense if I ever want to change this code? Can anyone else even read it? What is the end goal here and does this accomplish the spirit as well as the technical goal? What about related features that are likely going to end up related to this somehow? That and so many more things to think of that can change your direction, but long term really pay off rather than "code does thing, good enough". I say that having just read a bunch of code that only does one thing, could only do one thing, and now has to be reworked entirely because it can't do much else / be adapted.
  - JoeAltmaier 8y ago
    If that is the task (make code that can be changed) then work at that. How do you verify it though? My buddy Tom says, code isn't portable/changeable until you port it at least once.
    - duxup 8y ago
      Yeah I agree there is a verification problem. I certainly wouldn't try to tie any solid metrics or such to it. My thing is... did they even try? There's a lot you can tell that is not the least bit portable or changeable. If it doesn't meet some requirement in the future, oh well that happens no way to be 100% sure. But at least some effort might leave a path open, even if not optimal.
- gerbilly 8y ago
  I agree, and it's not surprising. Conscientiousness is one of the 'Big Five' personality traits[1], and it is the one most strongly correlated with success in any field.[2][3] [1] https://en.wikipedia.org/wiki/Big_Five_personality_traits https://en.wikipedia.org/wiki/Big_Five_personality_traits [2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2747784/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2747784/ [3] https://www.businessinsider.com/conscientiousness-predicts-success-2014-4 https://www.businessinsider.com/conscientiousness-predicts-s...
rcar 8y ago
"Most important"? My mother is a patient and detail-oriented person, but I wouldn't hire her as a software dev. To take a less extreme example, depending on the role I'd still rather hire someone who was occasionally impatient and didn't always write tests but knew how to code really well vs. a fresh grad who's always cheery and polishes the hell out of their work but takes a lot longer and produces meandering code.
- scoutt 8y ago
  If your mother is not a programmer, then (following the logic of the article) being a patient and detail-oriented person doesn't make someone automagically a programmer.
- ken 8y ago
  I would gladly hire her as a software dev over many of my former coworkers who were actual software devs. It's quite possible to teach a conscientious person to write programs. I haven't figured out how to teach a person who writes programs to be conscientious.
edw519 8y ago
I have always strongly believed that "Tech skills make you good. Other skills make you better." OP brings up a lot of good points (who could argue with these), but overlooks my #1 fundamental: If you can't write good code, not much else matters. I know lots of programmers who have mastered the technical skills but are weak at the other things, so no one would ever mistake them for "senior", no matter how good their code is. But I know many more "I.T. people" who are good at the "soft stuff" (analysis, design, product ownership, people management, agile, etc.) but can't code. I don't want to sound snarky, but these people are a dime a dozen. They often have great attention to detail and patience, but would you really entrust them to build your software? Learn how to build software first. Be able to do that well before adding the soft skills. That's the most important software dev skill needed. And it is most definitely "technical".
- devonkim 8y ago
  We’ve already seen a fairly consistent trend - high performing / good companies allow failure but do not tolerate incompetence. The bar for competency in software as an industry and profession is all over the place. Most white collar professions have some forms of basic competency that’s somewhat objective where interviews are almost entirely about the soft parts as a result. Meanwhile, most of us are grinding leetcode and Hackerrank...
- spdionis 8y ago
  > I don't want to sound snarky, but these people are a dime a dozen. Maybe this is influenced by geolocation or other factors, but IME actually competent "soft stuff" people are rarer than competent engineers.
- mpweiher 8y ago
  > If you can't write good code, not much else matters. Can't stress this enough and I frankly don't understand all these articles claiming otherwise, when even the most minimal reflection would clear things up in a jiffy: Take a skilled trapeze artist who has great attention to detail (I hope) and is patient (I hope) but cannot code. Alternatively take a brilliant software developer who is slightly sloppy and not very patient. Which one do you want writing your software? Of course, that's accepting that these are important skills/attributes. I don't actually agree they are. See https://medium.com/@petecam/why-laziness-impatience-and-hubris-drives-great-developers-to-script-301f46f431 https://medium.com/@petecam/why-laziness-impatience-and-hubr...
bitL 8y ago
I disagree, those are virtues one needs just to become a programmer. The only skill that matters in the end is velocity; these days you are required to deliver a 99.999% solution that solves some "unsolvable" computer science problem in a practical way within 3 months. Whatever helps you to get there is what you need to acquire, the rest is useless. This article seemed to me like a story from a developer that is just factually leaving being junior in practice (not in title) and observing there is a bit more complex world out there... I hope that person doesn't end up in management, enforcing their tunnel vision on everybody underneath, capping their capabilities.
- b_tterc_p 8y ago
  This sounds like a worldview guaranteed to burn you out.
  - bitL 8y ago
    That's why top programmers are more like top athletes; absolute focus, subordination of all activities towards their goals, delayed satisfaction. Companies that are lucky to get them crush the ones populated with regular, solid developers. That's why velocity is what matters in the end, if you have world-class developers.
    - b_tterc_p 8y ago
      Wow, you’ve drank more Kool Aid than the Kool Aid Man. I would strongly encourage placing less of your view of self worth outside of your “velocity”. That’s not the real world. Products will fail and it won’t be because you weren’t agile enough, it’ll be because the market is a jerk.
      - bitL 8y ago
        Let's say if you move slow, your probability of failure is 99.8%. If you move fast, your probability of failure is 97.3%. Which one would you choose as a company owner who wants to be a top dog? The whole Valley is based on velocity when you talk to and observe actions of VCs, disposeability of young programmers and how companies structure their own internal operation, inspired by military.
sammnaser 8y ago
I guess it's like saying the most important traits of a golfer are patience and focus. Sure, if you're missing those, you'll toxically spiral when you don't perform, but are those the "most important skills" in golf? Nope, I'd say those would be the technical skills that let you make the shot.
- mgoblu3 8y ago
  I think the perspective of this is assuming that the technical skill is there. You're totally right that the difference between a prime Tiger Woods and the field is definitely talent related. But when there's a lot bigger population who all have a similar level of technical skill and that's not the limiter, I can agree these things are some of the important differentiators.
  - sammnaser 8y ago
    You're totally right. I also acknowledge that it's hard to develop those technical skills in the first place without patience, humility, and a willingness to admit to more experienced people that you don't know what you're doing and want to learn from them.
  - enitihas 8y ago
    Also we should keep in mind that very few software developers are playing the PGA tour( working on rare problems). Most people are playing in local tournaments ( easy enough projects where the skill required is fairly low). And they need to do that every day of the year. In those environments the technical skills seem less important.
    - tmemfnskdj 8y ago
      This is so true. There is so much focus on social skills nowadays, I see it taking over someone with technical skills. It’s a double edge sword in my opinion. You have a bunch of agreeable software developers that cannot code outside their frameworks.
  - johnfn 8y ago
meuk 8y ago
I would argue that social skills are very valuable. At least, in the projects where I ended up, there are a lot of people writing code of debatable quality in a big, messy codebase. Asking around and communicating stuff helps you understand what's going on, and what to touch and where to stay away.
- apercu 8y ago
  Social skills allow you deal with the things around coding that lead to bad code. Social skills are underrated and we could all develop better ones.
deleted 8y ago
[deleted]
mr_toad 8y ago
If all a programmer required was patience and attention to detail then we could have machines do it.
CM30 8y ago
Also, knowing what to build helps a lot too. Many of the most successful companies and projects didn't come about just because there was a good developer/programmer involved, but because they identified a market with interest in it and built what said market wanted/needed. A lot of people will just build stuff they find interesting/fun to build, but no one will care. What they will care about is whether it solves their problems, and they'll often go for a hacky, poorly done solution that does if need be.
WheelsAtLarge 8y ago
No, I completely disagree. The most important skills, after being a competent developer, are being able to communicate and get along with our team. It took me years to understand this but without being able to work with your team you will not e able to create great software. It's possible to create a product that's not technically beautiful but it meets a real need in society. Ultimately we create software to meet a need. Once we understand the need we can go back and refactor it. But if we can't communicate and get along with our team then the chances of creating a good product are low.
bassman9000 8y ago
I’ve come to appreciate two important characteristics of good developers that aren’t unique to software at all. The title doesn't match the article's intent.
stunt 8y ago
Both hard and soft skills are important. When the subject group are above a certain level of hard skills, you can identify real seniority and leadership capabilities by looking into soft skills.

140 points by philk10 8y ago

bpyne 8y ago

The following are at least as important. - communication - compromise - curiosity

saiya-jin 8y ago
Communication is by far THE biggest issue in many projects. Especially with geeky introverty software dev types. Heck, my fiancee is a doctor and the amount of crap that happens in hospital just because people (other doctors/nurses/patients) don't communicate clearly, make tons of incorrect assumptions etc. is astonishing (and has direct consequence in quality and quantity of health care provided).

kharak 8y ago

"Attention to Detail" is my major weak point. I don't have it in coding. Give my a philosophical essay, a political discussion or an academic paper and I'll drown you in details, implications and references. Those come intuitively to me. Writing codes is completely different. I have to practice everything what others seem to do intuitively. I need checklists. I need to take notes. I need to review my task and codes several times. And still, I overlook the obvious and never spot the easiest implementation (even for trivial tasks like checking for empty Strings). All while it takes me a great deal of discipline to take care of the level of detail that is required. If someone here has/had the same problem, I'd like to hear their solutions.

dwrodri 8y ago
Just out of curiosity, is you background in web development and/or the C family of languages (i.e. C, C++, C#)? I mention these because they rely heavily on object-oriented and/or imperative programming paradigms. With C and C++, I still struggle often with striking a good balance between "writing a short solution that works well" and "writing code which is a joy for others to read". The former often relies on my technical knowledge and produces code that can be obscure to other readers, the latter often requires MUCH more concentration and attention to detail when writing. However, I have recently started experimenting with declarative and functional Programming. Coming from an imperative background has made "relearning" how to program quite difficult for me, but I've just started to see the "elegance" in higher level functional languages, such as OcaML and Haskell. Of course, functional languages are often MUCH better suited to different problems than OOP languages, but combining filters, reductions, maps and folds seems to activate the parts of my brain that are much more closely associated with the "classical logic" side of programming. I think you should check it out if you haven't already.
- kharak 8y ago
  You're on to something. I started with database programming, so mostly declarative. That was a joy and I did't need much time to catch up with the senior developers. Afterwards, I switched my employer and started anew with Java. I was completely overwhelmed and struggle to this day. Last week, I learned a little bit about streams and how functional programming works in Java. To my surprise, that seemed quite easy to understand. I don't really know why OOP seems so much harder for me to do.
  - jayar95 8y ago
    If you like the functional aspects of Java, check out kotlin. It's quickly become my favorite programming languages because you get all the benefits of java's strongly typed OOP system with a lot of elegant functional features, and type inference!!
  - mrfredward 8y ago
    Honestly, I thinks it's because a lot of OOP is awkward and forced. When it was the craze, object orientation became an ends instead of a means, and so it taken past the point of being clean and useful. Why do c# and java require every function, including main, be in a class? Why do we need static classes, which are really just a namespace for functions? There's no benefit to the programmer, it only serves the "everything is an object" paradigm. Certain OOP patterns, like the visitor pattern, are really just hacks to make OOP work like functional. I use c# everyday at work and for the most part love it, but there are certain problem domains (anything with significant multithreading) where forced OOP thinking just makes everything harder than it needs to be.
    - james_s_tayler 8y ago
      Curious, can you explain how the visitor pattern is like functional programming? What is it analogous to in FP? It's not a pattern I have ever really wrapped my head around fully, but perhaps there is some structure in functional programming that if I view it through that lens it will make much more sense?
- 8y ago
addicted 8y ago
I suffer from similar issues. Something that really works against me in the standard coding interviews. Some ways I try to mitigate some of those issues at work are: 1) Peer/senior code reviews. I try and get code reviews done by other folks. This helps with identifying something easy that I may be missing. Usually, once I already have a solution to a problem, I find it hard to revisit it without that solution overwhelming my approach, unless a bit of time has passed. Getting some fresh eyes to look at it helps. Also, explaining the solution to someone else often helps me identify issues with my solution during the process of explaining it to someone else itsel. 2) Practice and experience. I think for the most part intuition is simply the result of experience and practice. 3) Learning different programming paradigms. Something that has helped me more than anything else I think is learning programming languages that cover different paradigms. I’ve never coded anything useful in Haskell, but just the process of solving basic programming problems in Haskell, with its strong functional approach, helps me identify issues with the proceduaral/OOP code which I do write to solve useful problems. I think it allows me to approach each problem from multiple perspectives so even if I don’t have certain Haskell features available to me, it makes it easier to recognize that this may be an issue I need to address in my OOP code (for example, the Haskell compiler when pattern matching requires all possibilities to be addressed. Awareness of this fact means that anytime I’m writing conditionals checking the input I’m much more aware of the fact that I need to also handle the else condition, something that most non-functional programming languages don’t hsually require in their conditional constructs). 4) Related to #3m opting for better solutions wherever possible. I always try and opt for expressions over statements. I try to avoid state change as much as possible. I try and minimize side effects in functions, and try to constrain them in specific areas of code, etc. 5) Formal CS study. I don’t have a CS background, but studying formal CS in my free time has helped a lot. Getting better at data structures, algorithms, formal verification, etc, has helped develop my intuitions even if I don’t sctually use those data structures and formal verification methods in practice.
voidhorse 8y ago
I can speak to this issue as someone who comes from a formal background of philosophy and literature, but whose work involves a lot of programming (both reading and writing code) at this point. Foremost: practice. If you can read and write essays at a college level you've been practicing the craft for (likely) years. Most educated people in the US start engaging with letterforms as soon as kindergarten (!), and no later than 1st grade if not preschool. Contrarily, we don't start so early with the rules of logic nor programming constructs. Most folks don't start programming until much later, and even those who are precocious in this regard usually don't begin using "real" languages (in other words, not stuff like lego robotics or scratch) until they are ~13 or so (of course, there are plenty of exceptions). As with most skills, practice is invaluable. On a conceptual level, I found that making the jump from asking myself what does this code do to what does this code mean majorly beneficial. It may seem like a minuscule or pedantic semantic point, but it actually makes a world of difference. Just like essays, programs are expressing—they are saying something. If you shift from approaching programming from a goal oriented perspective to a communications perspective your code will probably improve immensely. I think this is the reason guys like Donald Knuth stress code readability and literate programming so heavily—at the end of the day, that's what's really important: communicating some idea—just like we do in plain old english. We simply have a broader audience (the latter part of which is very picky about what it understands). The notion of a proposition in logic doesn't do, it means. Programs are essentially a set of propositions which just so happen to have the side effect that they can make a device (a computer) do something when it interprets them. Just as linguistic commands ("go to the store") are "pure" and free of side effects in and of themselves—they only have effects under human interpretation. On a somewhat related note, I find stepping away from programming languages and starting with pen and paper is great. I think people tend to let programming languages get in the way of the real nature of what it is they're doing, which is solving problems in a structured manner, using mathematics and logic (algorithms and data structures). You don't need a programming language to do this, it's only a vehicle to express your solution. Just as you'd often start writing a formal paper by exploring your ideas in an outline or notes, or a couple of first drafts in which you hash things out, you can start "programming" by sketching ideas for solutions and better comprehending the problem at hand. This will ultimately help you write better code. I think a lot of self-taught devs, such as myself, miss this part early on as our entry point into the discipline is often through the languages and tends to kind of remain at the level of the languages we like unless we dig deeper into the underlying formalisms driving them. Too often people just go along with their first-pass understanding of a problem and begin reaching for the libraries, language constructs, etc. that they think they need. Someone with formal training, contrarily, has professors that can help them recognize the concepts behind the languages and connect up and distinguish the notion of a language as a mode of expression and programmatic problem solving as a practice irrespective of the selected language.

asaph 8y ago

> So many things have to go right just to get a software program to compile. That’s why attention to detail is so important... Even the sloppiest coders who work with no attention to detail still compile their code with ease. I get the author's larger point about attention to detail but I don't think compilation is an effective example to illustrate that point.

bmj 8y ago
Agreed. I generally see a lack of attention to detail with regard to things like linting, unit tests, and documentation. Our CI builds fail way too often due to the first two items, which can be easily done via a single build target on a developer's machine.
- asaph 8y ago
  A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.
  - swsieber 8y ago
    And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff. And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.
    - SketchySeaBeast 8y ago
      > And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.

asaph 8y ago

Continuous learning is also critical for success.

stuxnet79 8y ago

While the traits mentioned in the article are useful (patience and attention to detail), these are traits that are selected against in most work environments. Writing software "The Right Way" TM takes time and time is usually something most engineers don't have in abundance.

nukeop 8y ago

This goes against Larry Wall's virtues of GREAT programmers: laziness, impatience, and hubris. Impatience stems from laziness and made me look at entire classes of problems in a different way than many of my peers. It is crucial to the character of a proper developer and its lack cannot be substituted for.

johnrob 8y ago

The challenge of details is best solved via rigorous definition of “done” (i.e. acceptance criteria). If you don’t have consensus for that, there are a million ways someone else can re-define the problem and thus expose “incorrect details”. Many orgs delay this consensus, making for plenty of post code review work, but I don’t think that’s necessary bad so long as you don’t let PR comments hurt your ego.

deleted 8y ago
[deleted]

jaabe 8y ago

I agree with the author on patience, but I wonder if you can become a software developer without it. Sure some people will have more than others, but learning how to make code work is a terrible, terrible process and I’m not sure you can go through it without massive amounts of patience. I have a side job as an examiner for Danish CS students, and a noticible difference between first years and final project students is how they tolerate the frustration of having code not work. If you can’t sit through hours of not knowing why something just doesn’t work, you probably find a different field.

swsieber 8y ago
I think you can have different types of patience. Patience with getting something to work could be very different from the patience to build something correctly, which could be different from the patience to deal with people... But I agree - you probably won't become a dev without having or learning some degree of patience.
- jaabe 8y ago
  The thing about people is an excellent point. The ability to work in teams would be on my personal list, but the author seemed to direct it at patience with a technical focus.
- dahdum 8y ago
  In most situations I'm a pretty impatient person, but coding never seems to try my patience. Getting into the flow and working the problem is what I enjoy doing.
- mr_toad 8y ago
  Some people are far too patient to be great programmers. They are content with the daily drudge of slow, manual tasks, whereas a truly good programmer would become frustrated and desire to improve things. http://threevirtues.com http://threevirtues.com
JustSomeNobody 8y ago
> Sure some people will have more than others, but learning how to make code work is a terrible, terrible process and I’m not sure you can go through it without massive amounts of patience. I think this is more about being diligent than being patient. There are plenty (too many?) devs who will diligently try and figure out something but that have no patience when dealing with others.

linkmotif 8y ago

I'm not sure these aren't "technical" skills. Patience and attention to detail? In my experience that's part of the technical skill of programming.

brootstrap 8y ago
same thoughts here. I mean i appreciate the article and write up. My big skill is openness, communication, honesty. I have worked with many brilliant nerds who cant stay focused and literally contribute jack shit to major projects. They probably make the most $$ too. I dont care how good your program or app is. If you cant talk like a normal person, accept criticism, negotiate etc. You are going to suck. The best co-workers i have are able to combine both the CS tech knowledge with other skills like good estimation, honest and open communication, clear planning and execution etc. You can just tell in my opinion. Start workign with someone on a project for an hour and you can tell if they are a nerd without focus who spends weeks doing useless shit, or someone who will seriously contribute to your team and help get shit done.

rarspace01 8y ago

To be honest, after I started in software development 10 years ago, the most important skill is (good) communication. If you can't understand your stakeholders or express concerns the prettiest code won't help you. Obviously it will help, but only after figuring out the former.

Yuval_Halevi 8y ago

I pretty much agree with the author. I'm not a developer but I worked with many developers in the last 6 years. Some of them were great and some were not so friendly. -Respect for others - Being friendly - Give good energy to the people around you in the office - Learn how to work in a team Those are the things that when a good developer has, he becomes a game-changing part in a startup

C1sc0cat 8y ago
The attention to detail and not missing obvious gotchas is something that comes with age / experience.

JoeAltmaier 8y ago

Agreed; the single most important characteristic of an effective performer is Conscientiousness. Working at a task, measuring the result against a standard, working some more, until its actually really done. The absence of this causes havok: a task thought done will turn out not-done at the deadline and become an emergency. A feature not measured against all the requirements will fail in test or worse! in the field and cause customer angst and extra cost to everybody.

duxup 8y ago
Does this make sense if I ever want to change this code? Can anyone else even read it? What is the end goal here and does this accomplish the spirit as well as the technical goal? What about related features that are likely going to end up related to this somehow? That and so many more things to think of that can change your direction, but long term really pay off rather than "code does thing, good enough". I say that having just read a bunch of code that only does one thing, could only do one thing, and now has to be reworked entirely because it can't do much else / be adapted.
- JoeAltmaier 8y ago
  If that is the task (make code that can be changed) then work at that. How do you verify it though? My buddy Tom says, code isn't portable/changeable until you port it at least once.
  - duxup 8y ago
    Yeah I agree there is a verification problem. I certainly wouldn't try to tie any solid metrics or such to it. My thing is... did they even try? There's a lot you can tell that is not the least bit portable or changeable. If it doesn't meet some requirement in the future, oh well that happens no way to be 100% sure. But at least some effort might leave a path open, even if not optimal.
gerbilly 8y ago
I agree, and it's not surprising. Conscientiousness is one of the 'Big Five' personality traits[1], and it is the one most strongly correlated with success in any field.[2][3] [1] https://en.wikipedia.org/wiki/Big_Five_personality_traits https://en.wikipedia.org/wiki/Big_Five_personality_traits [2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2747784/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2747784/ [3] https://www.businessinsider.com/conscientiousness-predicts-success-2014-4 https://www.businessinsider.com/conscientiousness-predicts-s...

rcar 8y ago

"Most important"? My mother is a patient and detail-oriented person, but I wouldn't hire her as a software dev. To take a less extreme example, depending on the role I'd still rather hire someone who was occasionally impatient and didn't always write tests but knew how to code really well vs. a fresh grad who's always cheery and polishes the hell out of their work but takes a lot longer and produces meandering code.

scoutt 8y ago
If your mother is not a programmer, then (following the logic of the article) being a patient and detail-oriented person doesn't make someone automagically a programmer.
ken 8y ago
I would gladly hire her as a software dev over many of my former coworkers who were actual software devs. It's quite possible to teach a conscientious person to write programs. I haven't figured out how to teach a person who writes programs to be conscientious.

edw519 8y ago

I have always strongly believed that "Tech skills make you good. Other skills make you better." OP brings up a lot of good points (who could argue with these), but overlooks my #1 fundamental: If you can't write good code, not much else matters. I know lots of programmers who have mastered the technical skills but are weak at the other things, so no one would ever mistake them for "senior", no matter how good their code is. But I know many more "I.T. people" who are good at the "soft stuff" (analysis, design, product ownership, people management, agile, etc.) but can't code. I don't want to sound snarky, but these people are a dime a dozen. They often have great attention to detail and patience, but would you really entrust them to build your software? Learn how to build software first. Be able to do that well before adding the soft skills. That's the most important software dev skill needed. And it is most definitely "technical".

devonkim 8y ago
We’ve already seen a fairly consistent trend - high performing / good companies allow failure but do not tolerate incompetence. The bar for competency in software as an industry and profession is all over the place. Most white collar professions have some forms of basic competency that’s somewhat objective where interviews are almost entirely about the soft parts as a result. Meanwhile, most of us are grinding leetcode and Hackerrank...
spdionis 8y ago
> I don't want to sound snarky, but these people are a dime a dozen. Maybe this is influenced by geolocation or other factors, but IME actually competent "soft stuff" people are rarer than competent engineers.
mpweiher 8y ago
> If you can't write good code, not much else matters. Can't stress this enough and I frankly don't understand all these articles claiming otherwise, when even the most minimal reflection would clear things up in a jiffy: Take a skilled trapeze artist who has great attention to detail (I hope) and is patient (I hope) but cannot code. Alternatively take a brilliant software developer who is slightly sloppy and not very patient. Which one do you want writing your software? Of course, that's accepting that these are important skills/attributes. I don't actually agree they are. See https://medium.com/@petecam/why-laziness-impatience-and-hubris-drives-great-developers-to-script-301f46f431 https://medium.com/@petecam/why-laziness-impatience-and-hubr...

bitL 8y ago

I disagree, those are virtues one needs just to become a programmer. The only skill that matters in the end is velocity; these days you are required to deliver a 99.999% solution that solves some "unsolvable" computer science problem in a practical way within 3 months. Whatever helps you to get there is what you need to acquire, the rest is useless. This article seemed to me like a story from a developer that is just factually leaving being junior in practice (not in title) and observing there is a bit more complex world out there... I hope that person doesn't end up in management, enforcing their tunnel vision on everybody underneath, capping their capabilities.

b_tterc_p 8y ago
This sounds like a worldview guaranteed to burn you out.
- bitL 8y ago
  That's why top programmers are more like top athletes; absolute focus, subordination of all activities towards their goals, delayed satisfaction. Companies that are lucky to get them crush the ones populated with regular, solid developers. That's why velocity is what matters in the end, if you have world-class developers.
  - b_tterc_p 8y ago
    Wow, you’ve drank more Kool Aid than the Kool Aid Man. I would strongly encourage placing less of your view of self worth outside of your “velocity”. That’s not the real world. Products will fail and it won’t be because you weren’t agile enough, it’ll be because the market is a jerk.
    - bitL 8y ago
      Let's say if you move slow, your probability of failure is 99.8%. If you move fast, your probability of failure is 97.3%. Which one would you choose as a company owner who wants to be a top dog? The whole Valley is based on velocity when you talk to and observe actions of VCs, disposeability of young programmers and how companies structure their own internal operation, inspired by military.

sammnaser 8y ago

I guess it's like saying the most important traits of a golfer are patience and focus. Sure, if you're missing those, you'll toxically spiral when you don't perform, but are those the "most important skills" in golf? Nope, I'd say those would be the technical skills that let you make the shot.

mgoblu3 8y ago
I think the perspective of this is assuming that the technical skill is there. You're totally right that the difference between a prime Tiger Woods and the field is definitely talent related. But when there's a lot bigger population who all have a similar level of technical skill and that's not the limiter, I can agree these things are some of the important differentiators.
- sammnaser 8y ago
  You're totally right. I also acknowledge that it's hard to develop those technical skills in the first place without patience, humility, and a willingness to admit to more experienced people that you don't know what you're doing and want to learn from them.
- enitihas 8y ago
  Also we should keep in mind that very few software developers are playing the PGA tour( working on rare problems). Most people are playing in local tournaments ( easy enough projects where the skill required is fairly low). And they need to do that every day of the year. In those environments the technical skills seem less important.
  - tmemfnskdj 8y ago
    This is so true. There is so much focus on social skills nowadays, I see it taking over someone with technical skills. It’s a double edge sword in my opinion. You have a bunch of agreeable software developers that cannot code outside their frameworks.
- johnfn 8y ago

meuk 8y ago

I would argue that social skills are very valuable. At least, in the projects where I ended up, there are a lot of people writing code of debatable quality in a big, messy codebase. Asking around and communicating stuff helps you understand what's going on, and what to touch and where to stay away.

apercu 8y ago
Social skills allow you deal with the things around coding that lead to bad code. Social skills are underrated and we could all develop better ones.

deleted 8y ago

[deleted]

mr_toad 8y ago

If all a programmer required was patience and attention to detail then we could have machines do it.

CM30 8y ago

Also, knowing what to build helps a lot too. Many of the most successful companies and projects didn't come about just because there was a good developer/programmer involved, but because they identified a market with interest in it and built what said market wanted/needed. A lot of people will just build stuff they find interesting/fun to build, but no one will care. What they will care about is whether it solves their problems, and they'll often go for a hacky, poorly done solution that does if need be.

WheelsAtLarge 8y ago

No, I completely disagree. The most important skills, after being a competent developer, are being able to communicate and get along with our team. It took me years to understand this but without being able to work with your team you will not e able to create great software. It's possible to create a product that's not technically beautiful but it meets a real need in society. Ultimately we create software to meet a need. Once we understand the need we can go back and refactor it. But if we can't communicate and get along with our team then the chances of creating a good product are low.

bassman9000 8y ago

I’ve come to appreciate two important characteristics of good developers that aren’t unique to software at all. The title doesn't match the article's intent.

stunt 8y ago

Both hard and soft skills are important. When the subject group are above a certain level of hard skills, you can identify real seniority and leadership capabilities by looking into soft skills.