One day last week, my twitter feed pointed at a link to an interesting paper from researchers at Microsoft and UC San Diego that was originally done in 2008: Struggles of New College Graduates in their First Software Development Job. After reading the paper through, I wondered to what extent those struggles were due to a lack of training versus a mismatch between expectations and reality. When I was in grad school, I lived on campus in a residence hall on a floor that was me (studying electronic & computer music) and 25 first- and second-year law students. Law school appears to do a really effective job of taking someone who’s chosen the career on the basis of wanting to yell "no, you’re out of order!" to a judge after having seen "…And Justice For All" a dozen times and throwing cold water onto their fantasies of what the profession is really all about. Law students know early on whether they’re about to get into something that’s really not what they thought it was — the reality of being a professional software developer seems to hit a lot of people by surprise.
I thought it would be interesting to put the question to some of our developers:
"How is it better/worse/different writing code for a living than you thought it would be?" and got some interesting responses:
Budget
Matt Bajoras: One of the biggest differences about writing code for a living I’ve noticed is the pressure of budget. When I’m working on a project in my free time, I can decide to toss the architecture out the window as soon as I feel that it’s not going to work out the way I wanted. I can completely switch a project from one language to another if the first language gets tiresome.
As soon as I started doing software development for a living, the pressure of budget pushes these things out the window for the most part. Once I have a codebase, I have to build on top of that, even if I’m not completely happy with it. People don’t like to hear that they have to spend money on stuff and get no features in return. Also, there is not always the budget to implement my dream architecture on a project and I end up with a compromise between practical and perfect.
Christopher Keefer: There’s never enough time for ‘perfect’. As often as possible, you attempt to finesse ‘really good’ into being, but sometimes time pressures will force ‘as good as we can manage for now’. You WILL be called upon to revisit this good enough code (whether your own or someone else’s) at some point, when it is no longer good enough. The client will not be sympathetic to the plight their budget expectations has brought about.
Working with Humans
Chris Macksey: The unexpected part is that it’s the human aspects (mostly not the technical ones) that trump everything – unless it’s a one person project for yourself 🙂
Otherwise, you need to figure out what all the humans involve want (even when they don’t know or can’t express what they want well), and give them that as much as possible; you need to communicate with your team members and work within their personalities, strengths, and weaknesses. And, human craziness can destroy even the most technically brilliant project…
Making non-technical people understand this has been in my experience difficult and spotty at best – and how do you really explain “well, we’re going to work on the code for a couple of weeks, and at the end it will do exactly what it already does!”. I use plumbing and electrical (and even home stereo wiring) analogies, but they only seem to work in limited measure. Further, even if everyone involved *does* understand the value, taking the time to do this (and the attendant risks of instability) rather than pushing forward is often unacceptable. This means that inevitably, in any real code base, you end up with pieces you really *want* to fix, but just can’t – and you just have to live with that.
Ron Turner: Writing code for a living is ‘different’ than I thought it would be. What became clear after much too long was that the success of a given project depends, largely, on the quality of the communication between the people involved in the project. Sure, there are technical considerations that can have a very big influence on whether a project succeeds or not but I would submit that a project that lacks clear, timely, effective communication is almost guaranteed to fail.
Bradley Macomber: It’s more interesting than I thought it would be, in the sense that it’s a thoughtful challenge.
It’s more about understanding the real needs of real people in order to solve problems than it is about little details of a language. Most courses generally don’t mention that. Understanding what tools are available and being able to use them effectively in the right situation is certainly important, but being able to see the big picture is usually more important, at least to me.
I deliberately chose a comp.sci. degree over a fine arts degree, and I still think this was worthwhile for me, though you will get out of your paid education what you put into it. Working on a team during college, outside of class, was a hugely beneficial experience.
Christopher Keefer: Working with professional developers is different from working with student developers or on open source. There’s a confidence that comes with paid experience that is different from the nervous attention to the latest best practice (or their professor’s preference) that students exhibit, and a refreshing cordiality between peers that can be sadly absent from many open source projects.
Technology
Rich Zuris: Don’t be a fanboy of a particular platform, language, library, methodology. Focus on solving problems, not on what cool bleeding edge tool you prefer. Learn a broad range of tools and methods to broaden your appeal. You may start out getting hired because someone walks through a checklist of technical skills, but you will keep your job and be promoted if you focus on delivering quality work that meets the end user’s business objectives, and for that you must understand and advocate for that user’s needs, not by peacocking your technical prowess.
Christopher Keefer: You tend to get forced down paths that you otherwise would never have walked, and gain something in the journey. Building some line of business app may not sound as exciting as the project you would have chosen to take on in your spare time, but you’ll inevitably encounter some interesting problems (and, hopefully, solutions!) in the process, which you likely would never have encountered sticking to your comfort/interest zones.
Kevin Horn throws some flamebait out: Of course you should always use the right tool for the job. It’s not my fault if the right tool is almost always Python*. 😉
(* Ruby and other general purpose dynamic languages are probably about as good for most application-level work. Even JavaScript can work for lots of things, though it is Fraught With Peril. The “almost” is because sometimes you really have to use something that compiles to machine code. If the only thing you know is PHP, you *might* be a web developer, but you are almost certainly not yet a software developer.)
In my role here as Recruiting Manager, I talk to a lot of developers in various stages of their careers and see common patterns that surprise and concern me. I see developers so concerned with accumulating as many buzzwords and bits of alphabet soup on their resumes that their knowledge and experience of any one language or platform is paper-thin (when we look at code written by these developers, it often shows signs of "I can adapt my Java-centric design techniques into the syntax of any language you can name!"). Some come to us never having worked on a project of any significant size and are totally unaware of the challenges that accompany large, complex projects.
One that I’m repeatedly struck by are developers who are perhaps mid-career, have experienced some amount of success in their career working in some particular niche and has failed to keep up with the profession. For example, in 2013, the career opportunities for someone who only wants to work on Windows desktop applications in C++ using MFC are going to be limited. When we ask these developers about any experience they’ve had with more current tools and the answer is often curiously similar: "No, I haven’t had the opportunity to work with that…"
Maybe that’s my most important message to young developers no matter how old — we’re in a golden age of opportunity right now — cheap computers, cheap or free toolchains and more information to learn new things than anyone could consume in a lifetime. Explore what options there really are in the field — sometimes it looks like there’s nothing left but formatting database queries for display in HTML, but there’s no reason to restrict yourself to that corner of the world. More importantly, there’s usually nothing stopping you from that exploration except your personal inertia. When I first did work with embedded systems development in the early 90s, the tools were horrible and prohibitively expensive for an individual. Now, you can get started in that kind of work by picking up an Arduino starter kit at your local Radio Shack.
We can’t forget that we’re in a unique position in history — there’s a line about a group of young developers in Douglas Coupland’s novel Microserfs that’s stuck in my head since I read the book 20 years ago: "The cards are being shuffled; new games are being invented. And we’re actually driving to the actual card factory."
(Not technically a young developer? Last year I wrote a similarly-themed post for graybeards and those staring down the barrel of their mid-career: Playing the Long Game. Check it out.)
