Hacker News new | ask | show | jobs
by srikz 2360 days ago
I think a lot of the good practices and skills necessary to ship good quality software are not documented well (or formalized). That's why working with good teams and learning from good devs (or profs) is what determines the quality of a developer.

Also, time and again we see posts here lamenting the hiring process in this industry and we haven't cracked it yet. This adds to the demand-supply gap.

Anecdote: I have interacted with some of the 'overseas talent' and they were excellent programmers but lacked communication and hadn't fully figured out the mechanics of working in teams. Others from the same background but who decided to get a higher education from US had better exposure and generally fared better.

2 comments

Totally agree. Successful software engineering has almost nothing to do with clever programming tricks and everything to do with writing software that's empathetic to being within a commercial and team environment. That means writing software that takes into account that it will be read by others, used by others, and inevitably changed by others.

Interview processes at so many software companies don't do a good job of selecting for it. They still look for algorithmic competence and next to nothing about teamwork and structuring software projects.

I’d argue that many of these practices and skills are in fact non documentable/teachable (see the oft cited problem of teaching recursion/pointers to CS students, and that’s just one of many fundamental required things that are way more formally defined compared to “leading a team to ship consistently good software”). I’m sure many of us have seen very motivated, well intentioned junior developers who struggle very hard to push and improve their skills and still get completely left in the dust compared to the engineers who just seem to have a knack for it.

In this way software engineering resembles traditional craftsmanship more than any other discipline.

Methinks this is a property of a new (~50 yrs) industry, rather than an inherent property of programming.

Whereas programming itself has somewhat solidified, most of the programmer management/learning/etc. state-of-the-art still deals in nasal demons, i.e. much is still seat-of-the-pants experimental.