When you leave school and enter the world of professional software development, it turns out there’s a lot you don’t know. How successful you can be professionally depends largely on how well you can learn a lot of those things, especially the "less techie" aspects of professional software development.
This post is being live blogged from my session at DevTeach 2008 (Toronto). It contains my initial 8 Things followed by additional insights, lessons, and wisdom from others at the conference.
I was a bad real-world programmer
I was a pretty good computer science student. My grades were always good. I marked programming assignments for a while. I even won some programming competitions (yeah, major geek alert… I know). A few things I don’t remember learning in school:
• Maintaining and upgrading code is REALLY important
• Requirements always evolve
• Your code lives in an ecosystem where weird stuff happens
• Users will find ways to use your software in unintended ways
• The most work is in the unlikely or edge cases
It took me several years before I started to develop an instinct about the things that could go wrong with my code, its environment, or its users. For example, after you check that a file exists, it could still be deleted before your code gets to open it. Stuff like that happens (even if it is rare). Remember, the most work is in the unlikely and edge cases. You have to write all kinds of code that you hope never runs in production.
Newest / coolest / shiniest does not equal "best"
I got into computer science because I liked computers. I’m a bit of a gadget geek (although in the context of a conference like DevTeach, I’m probably in the middle of the bell curve). That pull towards the newest and shiniest toy extends into the computer world for me and I struggle with it constantly.
When Ruby on Rails was really taking off, I started tinkering with it and considered rewriting a project in it. Of course it is important to monitor innovations in the industry, but that thought was ludicrous. Thankfully I fought the urge.
Some of it was opinion
You hear a lot of stuff from comp sci profs stated in bold, authoritative tones that you are not supposed to question. But the truth is that many of them are so insulated in ivory towers that they are out of touch with the innovations and best practices constantly evolving outside of academia. Their perceptions about professional software development in some cases are 20 or 30 years out of date.
This is hard to swallow for some but… Assembler is not always the best choice (shocking!) and OS/2 is not about to make a comeback.
Not all smart people want to be geeks
Boy, did I ever struggle with this one for a while. It turns out that there are intelligent people out there who don’t want to understand the pros and cons of garbage collection and JIT compilation.
I’m thinking about two types of people here in particular. One is the software developer who isn’t interested in the "alpha geek" stuff. He/she wants to use good tools and follow best practices but isn’t interested in constantly chasing the shiny new things. This person builds stable and maintainable software and possibly has a real life outside of computers and the Internet.
The other is the person who works in the field but focuses on other things. He/she learns enough about the technology to get the job done. For example:
Biz Dev, sales, marketing, HR… these folks are REALLY important
It turns out that just writing code won’t actually keep a business going. I think a failure to recognize the importance of non-technical roles such as business development, sales, marketing, and talent management (HR) is a major reason startups founded by technologists fail or struggle with lackluster results.
Realizing this was a gradual process for me, but I become most acutely aware of the true important of non-technical people when I started running my own consulting firm. I wore many of the non-technical hats and although things went well for the most part, I gained a real appreciation for the importance of people who are trained, experienced, and passionate about these types of roles.
Your code must make or save more $$$ than it cost to make
This should be common sense, but boy do we techies miss it sometimes. Of course there are some partial exceptions such as R&D divisions, but ultimately the R&D group has to contribute technology that provides benefit to a company as a whole.
In the academic world, pragmatic concerns can hinder innovative research so they are pushed aside in the pursuit of pure research. That is important, please don’t misunderstand me. But the same professors who push aside such practicalities in the name of research can inadvertently lead awry their students headed into the world of professional software development.
You are a brand
How do you want to be perceived by employers? In the local dev community? In the national or international dev community? What do you want to specialize in?
You are responsible for your career. You must manage your career. Do not let the needs of a single employer consume your focus so much that you allow yourself to be pigeonholed in a place you don’t want to be.
How little I knew
They say a sign of wisdom is knowing what you don’t know. Well, by that measuring stick I was a real ID-ten-T coming out of school. I feel like I do better now. And coming to conferences like DevTeach help me to realize how much I really don’t know. :-)
And now from the conference…
Scribe for this session: Dave Lloyd from ObjectSharp
The biggest thing missing from University was Architecture. Was never taught how to Architect an Application.
Mismatch between the training of computer scientists and professional developers. Saskatchewan Institute of applied science and technology does offer a full year hands on project.
Overview of Technologies not specific to one area.
Gives you the confidence to know you can learn more.
Entered computing because he hated writing.
The business side of the industry is not taught at school.
Not marked on readability of code. Marked using Unit tests.
Managing expectations of customer.
Did not learn how to estimate the time it would take to complete a programming task.
Profs also had a difficult time estimating the time it would take to finish a project.
School should provide a source repository for all your assignments. (Waterloo has this)
Debugging was not emphasized.
How to write/update a bug report. How to see software development from the testers perspective.
That super awesome feature you thought of, you may never get to code it. You have to do the dull stuff instead.
Working with a team of people who you may not like or work well with.
Don’t leave school.
And more…
Nice post, I’ve got to try and not dwell on the fact that if you don’t know everything then I certainly have a long way to go.