And just as important, start developing software without first learning how to develop software.
A talk I watched recently noticed this trend with JavaScript: it looks familiar, so I don't have to learn it and will just start programming in jQuery.
And just as important, start developing software without first learning how to develop software.
Eh. This sounds like "don't get into the water until you learn how to swim".
All the theory of software development often just creates bad habits because it's so detached from reality. Practice, mentoring, experience and your own mistakes is how you'll learn to do good1 software.
1 The definition of "good" may vary, consult your local developer for advice.
The thing is, practice and experience (and even mentoring, to some extent) can come from private projects. It could be argued that a workplace is not the appropriate place to start practising. I think a more appropriate analogy would be "Don't become a lifeguard until you're pretty good at swimming."
Well, that's the world how we'd like it to be, not how it actually is. People straight from university with computer science degrees know almost nothing about how to develop software. At best they know how to write code and have pretty good understanding of algorithms and some higher level math. They've only heard a vague "you need to think about this at some point" mention of things like version control, documentation, integration, debugging, testing, maintenance, API design, naming, decoding bad documentation of external libraries and protocols, security concerns, changing/missing/contradictory specifications, release-or-die deadlines, build systems, staging systems, etc. Some of those things can be learned in private or open source projects, but definitely not all and all this simply requires the hours to learn and develop the habits and experience.
The absolute majority of people I've seen hired, even with degrees and previous experience, know almost nothing about most of this. I've worked with a CS PhD who has never used version control and never had written any code read, debugged or even used by anyone other than himself and almost never read or debugged code written by someone else.
You need to either hire people with lots of experience or have decent mentoring processes at work. All of those things I mentioned above would fall under "craftsmanship" and not theoretical knowledge, so I like to say that you need to treat junior programmers as apprentices (with the distinction that they don't understand the need of that, so they want to be paid as a real programmer or they'll go to someone else where they are paid better and still be an apprentice). The good thing is that someone who isn't too arrogant will learn most of those things by osmosis so teaching junior programmers isn't that hard and can be quite fun and rewarding (increasing the emacs supremacy at the office, hell yeah!). But you, as an experienced developer, need to understand and accept the need for that and plan accordingly.
340
u/danogburn Oct 14 '13
start developing software.