The most important software dev skills aren’t technical | Hacker News Reader

The most important software dev skills aren’t technical

spin.atomicobject.com

140 pointsphilk10115 comments

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.

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.

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.

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.

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.

> I think the perspective of this is assuming that the technical skill is there.

Of course if the technical skill is there then the most important skills will be nontechnical. :P

Exactly. The unspoken context undermines the point. It makes me wonder why articles like this gain any traction. What purpose do they serve?

Is it really a case people have the notion developers min/max their professional skills like it was a video game where only the level of "programming skill" matters?

I doubt anyone who comes across these articles have so little life experience to actually believe the lazy stereotype "developer" = "anime watching shut-in with no life skills and can't function in society."

So what _other_ purpose does the article serve? Who is the audience, and what value do they get? (I have my ideas, I'm just asking rhetorically.)

Yeah, the title is meaningless. I'd say the gist of the article is:

Attention to Detail and Patience are key, often unsung, developer traits

Thanks for this summary. I have to say, the most annoying co-workers for me are those without attention to detail. Absolutely hate those guys. I'm your reviewer, not your editor.

I believe he's using "Most Important" in the sense of necessary pre-requisites - and surely, those aren't technical, but behavioural.

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.

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.

> 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.

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.

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.

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.

> 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.

Ah, that's too bad.

We have one managed by yarn where I work, and it's only broken on me once. I occasionally get asked for help (maybe 1/3years/person) when somebody gets a cryptic error (well, not that cryptic, but they ask me because it's git related) from it, and rerunning the hook installation task has always fixed it.

This assumes that we are currently using a sane system. But your point is well-taken.

I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.

10 minutes?

A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed

This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .

> 10 minutes?

Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request.

The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?

Your local pre-commit hooks are separate to your remote pre-commit hooks.

There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge.

GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.

    git commit -m WIP

I hope you're rebasing that terrible commit message away before pushing this remotely.

I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.

No. No. NO.

My commits locally are my business, and 100000% orthogonal to what YOU (my teammate) will see when I'm ready to make a PR. Because I rebase, I reword commits, and I squash things as necessary before I submit a pull request.

The horrible conflation of commits (what I do when I want to save my work) and pull/merge requests (what I do when I want to integrate my work into the repo that everyone sees) is the very reason why git was created to begin with. If you want centralized version control where "commit" means "everyone sees it and it has to pass checks", use SVN. Seriously, get away from my tools.

Yeah, but none of that would be affected right? If you don't prepend the ticket number, it'll do it for you. That gives the entire team a guarantee all the work is traceable. It's a tool that serves the whole team, not just you.

Why should this be done at pre-commit time? And what automated system will be able to guess a ticket number based only on what's in a commit?

I'm all for validation that all commits must have some metadata/ticket numbers attached... at the time it is merged into master. Not on my local machine.

I probably did `git add -A && git commit -m WIP` at least 7 or 8 times today alone. But all my commits that made it into a PR were squashed, divided up logically, and renamed before they went in.

I'm trying to imagine a system where some automated thing prepends "TICKET#123 WIP" before every commit I make, locally, even if they're all getting thrown away before I squash/rebase/reword my commits. What's the point?

> 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.

Omg don't use commit hooks for that, just make it as easy to use as possible for the developer (e.g. integration into the editor/IDE). For verifying such things CI is the way to go.

Simply never commit directly to your development branch, use feature branches and pull/merge requests.

1. Someone else (ideally the most experienced Person(s) available but even any second pair of eyes is better than nothing) can and should review the code 2. Hook it up to the CI, the CI should merge it into the target branch locally and do its thing, as long as a pull request fails the CI it will not be merged

Software (e.g. Gitlab) to implement such a workflow is freely available, you just have to set it up but that's worth the effort.

Oh god, nobody effing documents anything. It's the bane of my existence. So much time would be saved if people simply documented things along the way.

This can be a double-edged sword when it comes to coding, as code and documentation can very easily fall out of sync. I am in favour of trying to write self-documenting code, with clear unit and variable names, with an automated system to convert that to a human-readable format. Any separate documentation should focus on more areas that are not easily concluded from the code -- like intent, architecture and the like.

Documentation of code tooling is terrible.

I still don't know why we haven't stolen the Photoshop layers paradigm and applied it to code

I should be able to toggle a shallow layer and deep layer all from a single 'file'

So the you'd be able to have architectural notes in the deep layer etc.

In many ways our tools are stuck in time.

Fascinating idea. Though from my experience with a crude approximation of part of it—Javadoc (or the equivalent) that's folded by the IDE—keeping the deeper layers up-to-date would be an uphill battle at most organizations.

Actually, the old Forth block editors did this with their screens and shadow-screens.

The normal unit of editing work in original Forth was a 1024 byte "page" called a SCREEN. You would write your code in an editor that arranged it as 16 lines of 64 characters. At the touch of a key (usually), you could swap to the shadow screen which would have the documentation on it. By convention, shadow screen comments were placed on the same line as the code they were remarking on, so everything was usually co-located.

By abusing autorepeat, it was even possible to "flicker" the code and documentation to see both at once.

Something like CWEB or org-mode permits interleaving code with comments, but it's one dimensional and breaks your flow when editing.

That's why it'd have to be layers and you'd have to have some clever way of keeping what in each layer goes with which code.

I started playing with it a while back in terms of how you'd structure it and what I came up with was something like

   foo.cs
   foo.shallow
   foo.deep

So that all existing tooling would work, foo.cs would just be regular old code and only if your editor supported layers would it care about .shallow and .deep, I didn't like that it would clutter up files.

If I ever get the time I'd like to implement a rough prototype in intellij.

I like this, in addition, I believe in documentation through unit tests. Especially when dealing with edge case business logic. Implement a test that has a verbose name or description testing that logic. If someone breaks it- they are notified through a failing unit test, then they also have a clear reference of why the logic was there in the first place and they know that now they have to go to product to figure out if the logic is still relevant.

I think that "self-documenting code" only covers the what, though. Code, regardless of style or language is fundamentally just a bunch of instructions; the why (and sometimes how, i.e. assumptions/preconditions/platform-level details, and so on) can't really be encoded there.

> I am in favour of trying to write self-documenting code, with clear unit and variable names, with an automated system to convert that to a human-readable format.

That's great and all, and I agree in principle, except time and time again I've witnessed people use the "my code is self-documenting" thing as an excuse not to describe anything they've written in plain English. Much of the time, it's pure arrogance of developers who think their shit doesn't stink.

I'm not expecting people to litter their code with comments explaining what every line is doing. On the other hand, a project that can't even run on a dev's machine without having to repeatedly ask someone questions is unacceptable, and core architecture and concepts should be summarized so that new developers won't eff up or rethink ideas that have already been thought out.

I've worked with people who struggled to get code to merely compile--and not just in CompSci 101 back in university where this was at least 80% of the programming students. In actual companies where they were hired as software engineers. Granted, they don't last long.

A lot of those folks see compilation success meaning program task is now complete. Some slip through the cracks and graduate.

Perhaps they meant to say compile on the first try. Then you need to have at least some attention to detail

Not every development language requires compilation. E.g. python

It's still getting compiled at some point.

At runtime, which is why you need unit tests and linting as part of your development process.

Still requires syntactic correctness to be interpreted. The fact it doesn't generate compiled objects is pedantry.

There's plenty of things which are only caught if actually run. I've certainly seen coworkers push code like:

    if case_that_im_not_going_to_bother_trying_to_test:
        obj.method_which_doesnt_exist()

That's the downside of duck typing, could as well be `obj.method_which_might_get_created_at_some_point_at_runtime()`

I rarely see code in python that I would both like to touch and that uses techniques of this sort.

You've been lucky, then. At half the companies I've worked for, there's that One Person who regularly breaks the build for everybody by checking in code that doesn't even compile.

This is 98% of why I push for continuous integration. I don't care about unit tests for their own sake, and I don't bother for my personal projects. I only want CI on a team so that when it turns red, there's an unbiased third-party building the code, and I can simply point to it and "the build is broken, please fix". Otherwise, I have to have the same conversation every week, and it always begins with "Oh, I don't think I caused that!"

Impartial enforcers are worth their weight in gold because they never get emotionally exhausted, they never get uncomfortable, they never back down and can't be argued with.

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.

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.

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.

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.

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

> 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.

Good clarification: "diligent" is definitely a more accurate word for what's being described.

It does require a certain level of patience. Then again, I've known a fair share of developers who will do just about anything to "make it work" even if it means copy/pasting snippets they don't understand.

"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.

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.

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.

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!!

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.

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?

This was exactly my thought as well: parent might find that a different programming language/paradigm suits their natural thought processes better.

Try out a Lisp, maybe, or even something real fun like Prolog. There's still details to be aware of, but they definitely have a different "flavor" that might be more palatable.

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.

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.

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".

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...

> 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.

> 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-hubr...

I agree that good code matters but I am not sure if it matters THAT much in some cases.

I write average code but always seek to make improvements. I'm always trying to improve my knowledge on OOP and learn about different approaches to architecture but at my company I could write garbage code and nobody would care. Recently, I tried to make an update to a legacy software and the code was quite bad, methods that were 15K lines long. Terrible variable names, UI elements named button1, button2 etc. However, nobody cared because it worked, it served it's purpose for the last 12 years, and yes it needs a complete rewrite, but it would probably need that anyway after 12 years as there are some major business changes.

I think every programmer should try to make things and try to improve. However, over-engineering and writing too many unit tests can also be a waste of time.

> over-engineering

Not sure why you think "great code" = "overengineering".

Great code is not overengineered, by definition.

So you write great code. Does your great code solve the customers problem? Were you even able to help the customer articulate the problem that needed solving?

Most software is written as a team nowadays. You may write great code, but how does it fit into what your entire is team is doing? Does your great code multiply the teams effectiveness?

You may have guessed it by now, but IMO for most cases communication is the first required skill, and then everything else. Obviously it's not the only required skill, but for me, communications importance cannot be understated.

> Does your great code solve the customers problem?

To me, "solving the customer's problem" is part of the definition of great code. Not sure what definition of "great code" would not involve that.

And again, we are talking software. So you have an awesome communicator who cannot code (and can't delegate...). Versus a so-so communicator who can code. No contest.

> Learn how to build software first. Be able to do that well before adding the soft skills.

We are all people before we are programmers, so I'd argue it makes sense to build people skills before programming skills :)

But I'm probably misinterpreting you.

"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.

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.

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.

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.

This sounds like a worldview guaranteed to burn you out.

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.

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.

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.

I would probably choose the company owner that wants to treat me like a human being?

I actually haven’t heard much in the way of military analogies besides Palantir if I’m going to be honest, and I’m pretty sure they’re up there amongst the least desirable companies to work for in my eyes

People like you are the reason people like me are QA/SETs. Your velocity, in my view, is some slapdash worked-15-hour-days-because-they-thought-they-could nonsense that is more likely to crumble under load and/or the first edge case that pops to mind. The only one capping their capabilities here is you mate.

You are naive. Did you work at world class companies that dominate their own market? They are exactly like that in the areas they are making money - they get the fastest programmers that could deliver world-class code. Not your typical half-baked developer quickly churning low-quality code in JS that breaks down after 5 seconds of load you get headaches from as a QA.

>You are naive. Did you work at world class companies that dominate their own market?

Seeing as I'm currently sitting in my office at Adobe I would say yes. There are plenty of code jockeys like you churning out low-quality Java/Python/PHP/C/C#/JS/whatever. You, despite what you may think, are not special.

> Not your typical half-baked developer quickly churning low-quality code in JS that breaks down after 5 seconds of load you get headaches from as a QA.

Cute. I get headaches from the guys who think they're great. From the ones who think that not documenting what they do is time wasted because clearly what this does is obvious. I get headaches from the people who have NO IDEA how their code actually performs and if there's any kind of slowdown well just throw more money at the hardware.

I can practically hear you and the others like you cry out, "But it works on my machine!" Oh the headaches that has caused.

> There are plenty of code jockeys like you churning out low-quality Java/Python/PHP/C/C#/JS/whatever.

OK, I landed #1 spot on HackerNews with a product I mostly developed (under a different nick) some time ago. You know everything about me as well. It was also competitor of one of your products.

All I am saying is that these are assumptions/metrics with which VCs/owners run/structure their companies and what actually matters to them. I have experienced it dozen times. I have also experienced when I had to fix somebody's horrible code in production developed in high velocity/high stress/low quality mode that was bringing one famous tech company down (lawsuits etc.), and had to correct spots I'd never seen before in some of the most complicated areas of the product dealing with provably infeasible problems (distributed systems). I'd also experienced an environment in a relaxed top company (rated higher than either of FAANGs) where we discussed ad infinitum just individual names of functions, their parameters and if they perfectly capture their meaning and refactored them daily; I don't have to say that project wasn't having much of a velocity and its market share reflected that.

The skill that matters is realizing that those wanting 99.999% solution don't know what they are asking for.

Most of the time they will be satisfied with an 80% solution.

Doesn't apply when you work for the best, they require 99.999% if 100% is not possible. 80% won't get them anywhere though it might be good for an MVP for Series-A startups that also crave velocity pretty much.

The first part seemed so much like sarcasm, that the second part left me in a confused state.

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.

Continuous learning is also critical for success.

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.

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.

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.

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.

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

[2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2747784/

[3] https://www.businessinsider.com/conscientiousness-predicts-s...

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

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

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.

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.

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.

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.

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

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).

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com