Programming: Things They Don’t Teach You At University — Part Two of Five
Part two of this series is about flexibility (if you haven’t read part one it can be found here). As with the previous post on teamwork, many of these points overlap the five categories of teamwork, flexibility (this part), planning, communication and organisation. I have tried to group them together the best I can, and hopefully this will be useful information to some.
Part two: Flexibility
Sometimes it just has to work
You may know about technical debt and code smell. You may have read about projects that were ruined by one dirty hack after another. When you work on your first professional code-bases they will most likely be much larger than any Uni project you encountered. Therefore it is really important to think through everything you do and make sure it doesn’t make the code worse, because those things can all add up. BUT, like so many things, it is all about balance. In a professional environment there are a lot of overlapping concerns, including promises and deadlines. There ARE times when you have to take the shorter option. Even if you know you need to improve and refactor that part of the code, but you could just alter it a little to make the change you need, sometimes it just needs to work. Just make sure you keep records, and schedule in time in the future to come back and improve it. We’d all like to write perfect code and live in a perfect world, but we also must be accountable and do what we said we’d do, otherwise all of our coding wizardry isn’t worth much.
Accept the ideas (and designs) of others
Another aspect of flexibility is to accept other people’s ideas. I kind of touched on this in part one, but if you can’t agree with a team member whose design is better, try and accept theirs. There’s probably not that much in it. Or perhaps suggest a middle-ground, which addresses both of your concerns. Don’t be a purist (I know it’s hard), you have to balance the personal relationships and the technical aspects then and there (it makes me angry when people say programming is easy).
Come out of your comfort zone
You might be good at one thing, so it’s tempting to stick to doing that one thing as much as you can. My advice is to push yourself out of your comfort zone, it doesn’t have to be a lot, but just enough to make sure you are always learning. Take on new challenges, problems, languages, frameworks, whatever it might be. Become more customer-facing, answer the phone. Try new aspects of your chosen language, you might have heard of a better way to do something. When you come across the right time to try it, just do it.
Everyone has bad days (including you)
This is another one that I couldn’t decide whether to put under Teamwork or Flexibility, but either way, it’s true. Just because someone can’t grasp a concept you are trying to explain doesn’t make them stupid. They might be tired, or have been working on complex stuff all day and are burnt-out. Be kind, because you will have off-days too. Additionally, don’t be too hard on yourself. It’s easy to feel inadequate when you’re the newbie on the team (lots of blog posts talk about imposter syndrome). Don’t beat yourself up, you will just get more tired and will lack confidence. Just accept that we all have bad days, but you are a good programmer, you just have to keep working on it.
Unexpected Issues
One thing that we learnt the hard way in our team was how to make reliable schedules. We would often fail to meet the weekly achievements that we had set out during scheduling. This was until our colleague gave us the idea of scheduling time for “unexpected issues”. We made a rota, with one person each day being in charge of unexpected issues. When it is their day, that person schedules less work than they normally would, leaving time for any arising issues. This also means scheduling less work in general for the week, but this isn’t really an issue, as you can always pull some tasks from the next week if you run out of work. We also found that this rarely happens. This made the team a lot more flexible, any queries from colleagues or external contacts could be handled by the person who was on unexpected issues that day, without them having to worry about not getting their work done.
Not just a code-monkey
You will often be asked to do things that aren’t coding. I probably spend 70% of my time actually coding, with scheduling and various team processes taking a part of the rest, as well as random issues that aren’t code related. Often there will be tasks that aren’t programming but need to be done by someone who understands the nuances of the system, or programming in general. This can be frustrating especially if you are in the middle of a new feature and have to schedule time to do other things instead. You are being asked to do these things for a reason, being flexible and getting them done may make you a more valuable member of your team/company. It can also be quite enjoyable to have a break from coding. However, it’s a very personal thing, if you are not getting a chance to write any code and it’s making you unhappy then speak to your manager about it.
Not just a Java guy/gal
Don’t be scared to take on new languages. In my job, I’ve had to work with Visual Basic code, when I previously had no knowledge of Visual Basic. Of course, be honest and say you have no experience but you’re willing to give it a try. Programmers are problem solvers, and code is code, your knowledge of languages does matter, but not nearly as much as recruiters/interviewers think it does. Good programmers enjoy hard challenges and are tenacious.
That’s it for part two, come back next week for part three: Planning! (edit: part three is now live and can be found here)
-Mike G
