I’ve been developing software for nearly 10 years now for a few different companies in various roles and i’d put myself in the “pretty experienced” category. I’ve certainly not seen it all but i’ve seen enough to know what makes a good idea and what makes a bad one. First up, I don’t like dealing with clients, they invariably want the moon on a nice handy stick. I don’t like dealing with people, the always get in the way of my code fun and I certainly don’t like dealing with legacy systems as I usually want to re-write them all from scratch just to service my new addition better. But with this said, clients can be fun, people can keep out of the way and legacy systems are a veritable playground for developing skills and understanding, learn to deal with them and your life will be much less stressful. The aim of this blog post is to basically share some of the things i’ve learnt about the different situations you may find yourself in as a software developer.
Project kick offs and meetings
Being a techie, sooner or later you’ll get invited to a project kick off meeting. This is where all necessary parties, usually one or two from each relevant team gather to decide how a project is going to be tackled. You may have been briefed already, you may have already been asked to spec out a rough game plan or solution, you may be even bringing to the table a fully fledged design document. Whatever situation you find yourself in, my first point is, turn up prepared.
1. Be prepared
Before the kick off meeting starts, the best thing you can do to speak to others in the business who know about the project. Find out the business requirement that is driving the features you are expected to deliver, speak to the stakeholders about what they think you will be delivering, if it’s a big project, go away and do some research into possible solution architecture, has anybody solved this kind of issue before?
This is the single biggest piece of advice I can offer. So much so that i’m going to say it three times in capitals, LISTEN LISTEN LISTEN. As much as we like to think we know everyone else’s job better than they do themselves, more often than not, we do not. Listen to what people are saying and understand it. If like me you sometimes struggle to keep up with some concepts which you are not familiar with, write them down and after the meeting, Google that shit. Nobody is expecting you to know everything but we don’t want to make the meeting last longer than absolutely necessary.
One other key thing here is who is talking. If there are more senior people than you in the group and they are putting in their 2-pence, pay particular attention to what they are saying. What parts of the project are of concern to them? How do they see the project unfolding? Try and understand not just the points they are making but their angle, ask yourself, yes Dave is concerned about X but why would that be an issue? If in doubt, ask Dave, “why would that be a problem?”, if you don’t know it’s an issue, you sure as hell can’t cater for it in the build.
Lastly, and it seems quite obvious but don’t switch off in meetings, sooner or later you’ll miss something important that will cause you a headache down the line. LISTEN LISTEN LISTEN!
3. Hold your ground
We’re quite a proud bunch us techies and we often see problems or questions about a solution we’ve built as a direct criticism of our work or integrity. While this is probably not the case, don’t sit by while others shun your ideas, especially if they are directly related to the technical solution, remember, you are the developer and you know best. If you can see something is going to be a problem, be quite clear with your reasons as to why, if you don’t, you’ll have to deal with it further down the line where it can cause a lot more issues.
Lastly, don’t be dictated to with regards to the technical solution/implementation. One thing i’ve been trying to do recently is to get people to give me the problem and not the solution. This is sometimes very difficult but try to coerce it out of your colleagues, “don’t tell me what you want, tell me what the problem is”. You may find what you are being told is very far from the best solution, it’s just a case of trying to find out what the problem is in the first place. Chances are you can build a much better/cleaner solution than what is being suggested to you, sometimes the solution being suggested is not even solving the underlying problem and you know what this is called? A waste of time.
4. With bigger projects, be patient and don’t try to architect a solution on the spot
When working on a big project, the absolute worst thing you can do is reveal your solution in the kick off meeting, even if it’s pretty obvious. Always stick to point 2 & 3 above and try to end the meeting with “ok, i’ll go away, have a dig around, speak to my colleagues and let you know solutions and timescales”, trust me, i’ve never regretted doing this. The amount of times i’ve left meetings and had ideas later on, don’t commit up front, you’re wasting everyone’s time.
Pretty much guaranteed at some point in a meeting you will get asked that awesome question “so, how long is it going to take?”. As I mention in point 4, try not to give estimations up front, as much as people say “you wont be held to this” or “yeah we understand, just a ball park”, these are in fact big lies and the first time you commit will invariably be what you get quoted as saying in all future meetings. Take you time, figure out your solution, break it down, guess at all parts individually then double the total time. Any good project manager will also add-on a percentage of their own. Estimating is a necessary evil, don’t sell yourself short, the worst case should be you bring the project home early and who doesn’t like that?
Coding on bug fixes/features
1. Speak to the person who raised the issue/feature request
If you use an issue tracker or the problem has been spelt out for you, regardless, go and find the person who raised the issue to confirm any suspicions. If it’s a feature, make sure what is being requested is actually solving the issue. If it’s a bug you are asked to fix, ensure the problem is not actually something else going on elsewhere and that your understanding of the issue is correct. No one like having to revisit a fix because it wasn’t correct or wash;t required in the first place.
2. Understand the code
If the code is well commented, chances are you won’t actually need to read the code itself which is a real shame, but I’m a massive fan of commenting. It’s a lot easier to infer functionality from a comment than the code itself. If you are working on legacy systems, take the time to follow any included classes or libraries and see what they do, if the code consumes an external resource/api or solution, go and find out about it.
3. Read the code
a) It’s not necessary to read the entire file when you are making a change but at the very least, read above, below and trace any function calls. If you can see what’s going on, it’s not only a lot easier to affect your change but also prevents you from inadvertently adding in “features” (bugs)
b) If you know the code has been written by someone more experienced than yourself or who is better with the technology than yourself, take 15 minutes to look at their coding style and syntax. This is my second biggest piece of advice here, most of what i’ve learnt in the last 10 years has been through reading the code of others (ever inspected the jQuery source?). You can learn more in 15 minutes looking at peer code than any other method. Look for syntax that you don’t understand or function calls/syntax constructs you don’t usually use and ask yourself why? If it doesn’t make sense, go a find the person who wrote it and ask themselves to explain it to you.
When making a change, if you see something that has holes in or some code that could be tidier/more succinct, take 15 minutes to rewrite it, the business and your colleagues may not thank you for it but may make all the difference to a solution over its lifetime. My general rule is, a piece of code is out of date as soon as you save and close the file. This can’t be helped, but If you open a file thats not been looked at for 6 months, chances are design patterns have moved on, coding style has changed, the person who wrote it has left or simply, “we know better now”. Technical debt is a massive issue with ANY company that has a codebase, the most important point here is don’t defer this stuff. Imaging you make your fix, you close the file neglecting another issue you’ve seen, someone else opens it up and hacks at it a bit, sooner or later, a few “quick wins” down the line and you’ve got yourself a massive ball ache. Rewrite little and often, every time you open a file, try to find at least one line of code to modify for the better, “a stitch in time saves nine” (my mum taught me that
Coding on projects
1. Don’t write any code
That is, don’t start by writing any code. Up front you should be doing everything BUT write code. Let’s assume you’ve received the spec, been to the kick off meeting and understood and agreed what is going to be delivered. Your next step is to plan. I’m not a fan of big design up front but it is necessary however to get a feel for the project and what direction it may take from a software solution perspective. No one ever knows how the solution will look in 6 months to a years time, business and people change etc but you should spend some time considering it. Consider other developments in the business that are currently in progress or scheduled in. Does this project relate to those and should your solution take them into account? Is there any overlap or code/ideas that can be shared? Lastly here, has anyone worked on a similar project or got experience in areas you will be touching, what can you learn from them? Even if they tell you something you shouldn’t be doing, thats a #win.
Think about the problem and what ideas/methodologies are best suited to providing the required solution. Try to think outside the box, we all have comfort zones wether it be software or a particular framework or whatever, get yourself out of those and challenge yourself, “regardless of what I know, what does the best solution I can provide here look like” and “how can this project best service the business/client both now and in the future”. Of course the project is I direct response to a business need but in my eyes it’s so much more than that. I like to think of them as opportunities to change the way the team works or improve business process. You should be asking yourself, how can I use this project to make my life/our lives easier in future. If the project is split up into phases, don’t get bogged down by them but definitely consider implications.
2. Speak to others
In all likelihood, you don’t know everything. And even if you did, the best solution isn’t for you to solve this problem on your own. By all means draft up a solution but when you are happy, take it to someone else and ask them what they think. Even if you’re John Resig, a second opinion never hurt anyone. They may notice something you have missed or may understand a particular concept or part of the business better than you. They should also challenge your ideas, even if you end up at the exact same solution, at least you will know your solution is the best your team can offer.
When a project comes to a close and you have delivered a working solution, eventually someone other than you will be called to make changes to it. Think about this as you build your solution. Throughout the lifetime of a project, get colleagues to review your code regularly, bounce ideas off of them and generally keep them in the loop as to whats going on. One thing I like to do is on completion of a project, take half hour with the rest of your team and walk them through your solution and do an informal Q&A. Try and give them some understanding of what it is you’ve done, what the problem is that you have solved and how if required they should go about making changes. Communication is vital, no one likes working on an unknown system written in an unfamiliar language by some guy who left last week.
3. 3rd party/off the shelf software
Working in the open source space is so much fun, quite often, the problem i’m trying to solve has a) already been solved by someone else and b) their code is available free online, this gives me the massive benefit of being able to get projects up and running very quickly. While this obviously awesome, it doesn’t mean you have to take your eye off the ball.
Firstly, because it’s published online, doesn’t mean it’s any good, anyone can publish anything these days. If it’s a repo on github, how many followers does it have? When was the last commit? If a change hasn’t been made for 6 months, potentially the project has been canned and is no longer supported, how will this affect you?
If you’re using code from a website, you should definitely take your time to look through the un-minified version, look for potential holes and pieces of genius (we can always learn something), ask yourself, is this the best way to solve this problem? If you don’t understand parts and you have the time, chuck some debug statements in to get a feel for whats going on. The number of times i’ve included packages only to find a month down the line there’s a massive security hole or the code is flakey as hell, trust me, 5 minutes spent now may save you a complete refactor in 2 months.
To conclude, you may notice I have not cited and references, that’s because it’s entirely my own opinion. As such, it may not work for any/everyone so take or leave what you like, if somehow though any of this can be helpful then yay! It’s not often people ask me about this kind of stuff but somehow it’s been really useful for me to write it down.