Universities don’t have the time or scale to give undergraduate software engineering students a complete sense of what it’s like to work in industry, which means there can be some eye opening moments for many graduates once they leave tertiary education and become an IT professional. I’ve prepared a list below containing some of the big ticket items that might surprise many a graduate upon entering the industry, but will be commonplace to seasoned engineers.
This list is not meant to be definitive or exhaustive, but it does capture key moments that many graduate developers will go through, depending on where they land their first development job.
So here’s the list:
Release code you aren’t proud of
Work with someone more experienced than yourself
Work to someone else’s deadline
Work long hours
For each item, I’ve included examples of (likely?) reactions from graduates, trying to cover both ends of the spectrum of reasonableness. I’ve also included links to seminal text books which provide a lot of extra knowledge around the item in case anyone reads anymore.
1. Release code you aren’t proud of
Firstly, a basic home truth: given enough time, 100% of your code will become something you no longer take pride in 😦 With time comes experience, (hopefully) skill and exposure to alternate ways to write code and all these changes mean you look back at the code you’ve written and see how differently you would write it now. In extreme cases, you struggle to even associate any of your old code with how you see yourself as a developer now.
But it’s not the above situation that this item is about – it’s when you release code that you know at the time is not your best work, but external factors prevent you from fixing/improving the code. The typical scenario is project deadlines forcing you to move onto the next piece of work as soon as you have the most basic working version of a solution to your current piece of work.
Even as a graduate developer, you’ll be starting to build a spidey sense that tells you whether the code you’ve written is ugly-but-perfectly-workable versus ugly-and-potentially-buggy. Where the code falls on this spectrum should dictate how much energy you use to push back against the forces preventing you from working further on the code. It also helps to have an estimate of how much time you need to bring the code up to a level you believe is truly production-ready. Sense checking this feeling with a more experienced developer is critical at this point, lest you are being overly optimistic or pessimistic with your estimate.
The other side of the equation is understanding just what is behind the opposing forces: How tight is the deadline? Are the consequences of missing the deadline too high? Is the importance of your code high or low relative to these forces?
Poor Reaction #1
Say nothing, do nothing. Accept this as a fact of life and move on.
Poor Reaction #2
Use only your own counsel to gauge whether your code is ready for release. Refuse to budge even an inch until you have achieved code which meets your standards.
Refactoring (Martin Fowler) – For theory and practical advice on how to incrementally improve the quality of the code you’ve written
2. Not Coding
“Not coding” can mean lots of things, but it will most likely be related tasks like testing, writing documentation or working with customer support or operations teams. You will be often be assigned these activities as part of a larger on-boarding process, and the rationale is usually along the lines of:
- Increasing your level of knowledge around the business environment in which the code runs
- Giving you a softer introduction to your role than throwing you in the deep end immediately
- Buying some time during a critical activity for other people to become free to support you
If you’re not coding in the early stages of your career, it is key to understand the reasons for this (hopefully they align with the above) and how long this stage will last. Make the most of the information you collect during this stage and the people you’ll meet. Use all this context when you finally sit down to solve their problems.
“I’m a coder. I code. Testers test. Technical writers write. And ne’er the twain shall meet.”
The Pragmatic Programmer (Andy Hunt and Dave Thomas) – so many gems of wisdom for programmers of all ages, but includes general career advice as well
3. Work with someone more experienced than yourself
This can come in several forms; some companies have explicit mentor arrangement for junior developers, in other cases, it could be the natural side effect of coming into a team with more experienced developers, or it could be a more disciplined team culture of pair programming that finds you spending a lot of time developing with senior engineers.
Whether this is a deliberate master/apprentice coupling or just opportunistic, there are so many benefits to working in this scenario. Senior developers understand the business domain, codebase and technical stack far better than you and will know where the gotchas lie. They will know the architectural and design patterns intuitively: things that can take a long time to sink in. They will also (likely) know the key people around the work which will make navigating the informal communication channels far easier.
Having access to a good mentor(s) can have a significant impact on how quickly a graduate developer picks up speed in their career. Having an open mind and a willingness to listen is vital. Be careful not to blindly accept everything you hear/see though – working with more experienced people doesn’t mean you turn your brain off and take no responsibility for the work being done. Good mentors should welcome questions from enthusiastic junior devs.
“I’ve got this – hold my beer (after all, I did get great grades in my software subjects at university/college).”
Pair Programming Illuminated (Laurie Williams) – Laurie was one of the first people to do empirical studies on the effectiveness of pair programming.
4. Work to someone else’s deadline
It’s very, very rare (i.e., unicorn rare) to find a development project with completely elastic deadlines. Deadlines are derived from pressures; market pressures (e.g., what is the market demanding, what is the competition doing, when is the next big event we’re targeting), budget pressures (e.g., we have to get this done for less than $X), timeline pressures (e.g., end of financial/tax year, in time for the System X upgrade in Q3).
Whatever the pressures are, some poor sucker derives a schedule that will clearly show that the work will get done by the required deadline and then the starter’s gun fires: it’s now down to your team to make the plan a reality (note: massive oversimplification here). And whatever the pressures are, the presence of a deadline and our general inability to predict what course a development project will follow inevitably means time allocated to work will fall short of the time needed to do the work… and how people react to this reality is often the difference between success and failure, at a individual level, team level and so on up to the overall success (or failure) of the program or even organisation.
“Is there anything I can see in the work I’m doing that could be done simpler, cheaper, quicker? Is all the functionality needed for day 1, or can some wait until a later release? Am I spinning my wheels by struggling to finish my work solo for the benefit of my own knowledge, or am I asking for help regularly, even if it means I don’t understand 100% of what I’ve done?”
Is this deadline affecting everyone involved, or is it really just the development team?
“They cannot possibly expect me to finish this work in 2 weeks! We originally estimated 6 weeks and none of the scope has changed. And what about the 2 month delay to the start of the work?!? Why didn’t that change the deadline? Even as a graduate, I can see the lunatics are running the asylum!!!”
Software Estimation (Steve McConnell) – sheds some light on the risks around estimating software and will help make you a better estimator as a consequence (p.s., you’ll still be wrong most of the time though :-))
5. Work long hours
Given the likelihood you’ll be working to a tight deadline, a lazy but very common reaction from those ultimately responsible for the delivery of the work (most likely a project or program manager) is to ask the team to work extra hours to meet the deadline. This request could come in the form of longer days, or weekends, or a block on taking leave, or any combination of these. For all the enlightened conversations around the IT industry, when push comes to shove, we invariably fall back to cracking the whip to meet a deadline with very little in the way of compensation for our efforts.
But unpleasant though these situations may be, it’s important for graduate developers to experience these environments at least once for there are many lessons to be learnt from these situations.
Have a good understanding of how much time you’re willing to give for the cause and how critical this time of yours will be to meet the deadline. There’s no point if you work 80 hours weeks on work that is nowhere near the critical path of a project.
My experience has shown me that short bursts of long hours can help considerably in these situations. By “short bursts”, I mean effort measured in days and possibly weeks, but definitely not months.
Poor Reaction 1
“My contract says I work 37.5 hours a week. I’ll see you at 9:00am tomorrow.” To me, this is a sign that your treating this as a job rather than a career. Being successful in any career requires you to undertake some personal investment and being completely unwilling to budge is not a path to enlightenment.
Poor Reaction 2
“What day is it? I’ve been sitting here coding for so long I cannot really see the screen anymore, but I’m sure another 3-4 hours is all I need. And where’s that pallet of Red Bull I ordered?”
Death March (Ed Yourdon) – sometimes working long hours is taken to the extreme, and these situations have a suitably
The Mythical Man Month (Fred Brooks) – this book isn’t guaranteed to help you fight the battle over long hours, but will equip you to understand how the situation may have arisen.