Top 10 Developer Mistakes
Every developer makes mistakes - all the time
If you’re an experienced developer, you’ll hopefully have learnt from your previous mistakes - and you’ll be making new mistakes now
And yes, you’ll still forget the odd semi colon!
You’re likely to work for customers who want you to work fast and hard so to decrease your chances of heinous blunders you’ll need to put a few checks in place to avoid catastrophe.
Our Top 10 Developer Mistakes below are a general common-sense guide for developers and a best practice sanity check
Remember that however experienced you are – nobody is unstoppable
Let’s face it however – if you don’t make mistakes you’ll never learn - and you’ll need to take a few risks to innovate and get ahead of your competitors
1. Don’t be a one trick pony
You should never stop learning so don't focus all your energy solely on one technology
You may be the Don of your language and that’s splendid - but you’ll be more marketable and better able to help your employers if you can use a variety of technologies and understand which will provide them with the best solutions
At the same time, don't fall into the trap of listing lots of new technologies on your cv just to make yourself look better. Use your new languages only if there is a real benefit to your project and they are capable of being maintained
The world of tech is moving faster than ever, and it is important that you don’t get left behind just working on old legacy systems if you want an interesting development career.
Whether you’re an old timer or junior developer it is never wise to get too obsessed with your language, library or framework at the expense of all else. Look into other languages that complement what you already know and get out of your comfort zone. It will change your mindset and is likely to improve your work overall
2. Trusting your customers to know what they want and why
Your end users or stakeholders may not speak the same business language as you. They’re unlikely to be developers, so their requirements may need translating into something that makes sense for your team and your response equally may need translating back to them
A good project manager should help the two sides communicate but it is never wise to assume you totally understand what they want. Sometimes your customers can be guilty of not knowing what they really want themselves!
You may have created an app with features that your team feel is mind-blowing - but it might be too complex for the average user. Will they use it in the way that you think they will? Is it idiot proof? Is it solving their real issues?
Get your end users involved in testing at appropriate stages – sometimes simplicity is the best option. It is essential that you create what they really need and want - not just what you think might be great
That may sound slightly brutal but the clearer both sides can be from the outset the fewer changes and iterations you’re going to need to go live with the project. You may have to manage your customers' expectations carefully, but it is equally important that you have a good understanding of their end of the business too - so you can provide them with the perfect solution
We've all had to deal with customers who constantly change their minds and shift the goalposts - don't feel that you must agree to all their requests without question. Try to work with them as a team where possible and present them with the advantages or disadvantages of the options open to you
There are some developers who take a defensive stance - often through sheer exasperation of trying to deal with a raft of constant requests throughout the years. Although some may be defensive to give themselves more time or even to avoid complex work. Don’t be that developer. Be the one who helps the company grow but sets realistic expectations and works together with the end user where possible
3. Flying by the seat of your pants
Sometimes you know deep down that you’re kind of winging it as a developer. Maybe you’re new to it all or feel that you have too much work to be able to do everything you need.
We all get that feeling sometimes but try to ensure that you don’t ignore the basics.
Think about user behaviour and how your users may do crazy things that you wouldn’t have expected. Think about all the little things that might make your code break – character lengths, date formats, usernames.
Ensure that you
- Always use good Unit Tests – (automate it if you can)
- Use a good version control system e.g. CVS, Subversion, Git (go back to when it last worked if you must)
- Choose a good development methodology and stick to it (work as a co-ordinated team)
- Maintain your code for the long term
- Analyse your code – has it been built carefully, methodically and correctly?
- Are good friends with your team and that they’ll help you fix an issue if it is urgent (and that you will help them)
Simple mistakes can be extremely costly to your company and possibly even your own reputation
4. Being the wrong person in the wrong team
There are some great developer jobs out there – make sure you take the one that is right for you by asking lots of questions – not just about the job itself but the company culture, team, management, workstyle etc.
Are you going to fit in? advance your career? learn new skills? really enjoy being part of this team and tackling new challenges together?
Have a think about how others perceive you too – make sure that you’re not one of the ‘elitist’ software engineers who thinks they’re above everyone else
You might be the don of your language, but a team of dons is even better
Share your knowledge and help your team achieve success together – it’ll be much more enjoyable that way and you'll learn much more too
5. Thinking Documentation isn't necessary
Document your code like a demon. We all hate documentation but leaving it out will come back to bite you. You might think that you (or most likely others) can try and figure out what is happening from the source code or reverse engineer the functionality – but why make it hard? New members of the team may have a sketchy understanding at best of what the application does. You might even forget what it does yourself in time!
I saw Scott Matthewman from www.Skillsmatter.com talking at an LRUG Meetup about documentation and finally the penny dropped as to why it is so important
Scott points out that you need to focus on who you’re writing the documentation for. It’s never yourself – you’re the one who knows why you coded it the way you did. He suggests pairing with someone else who didn’t write the code, so your documentation makes sense to others
You don’t need to create tons of documents, but a requirement spec and technical document might go a long way for a start – and you need keep it UPDATED
This must be part of your development process and must always be followed. The pain it can relieve when your application is live and being supported by others is always worth the effort
6. Not being a backup believer
BACK UP EVERYTHING!
Have you ever deleted data and accidentally committed it? As an inexperienced junior DBA, I often made heart stopping mistakes that could have impacted the business I worked for seriously. Luckily, I had a great working relationship with the Senior DBA which meant he was forgiving, would always retrieve the backup quickly and rectify my errors if I bought him a pack of crisps first (cheese and onion)
Without a backup my company could have lost millions and I would have likely been frog marched straight out of the door
If you have everything backed up it allows you to go to where you were before you made a mistake – it is essential for your company’s future and your own piece of mind
Full control and access should never be given to those who don’t know what they are doing or may even have malicious intent – the issues it can lead to could be crippling to the business
Don’t give great responsibility to those who shouldn’t have power
& Don’t accept great responsibility if you’re likely to mess it up
It is always wise to educate more inexperienced members of your team on the risks involved and ideally only provide limited access for data modification – all with the addition of an automated backup
7. Failing to fully test your code and create error logs
Audit and verify that your code works as soon as it is launched and that it hasn’t affected any other applications or units of code. This is non-optional!
You can potentially automate unit and integration tests to save you time and effort in identifying your software’s side effects
Your end users might not ask for error logs, but they are sure to expect the software to be maintained. If you want your software to be consistently stable, then error logging is vital. You never know where your code may fail, so monitoring error logs and resolving those issues as they arise will only make your software more reliable
8. Trusting other developers' code or reinventing the wheel
There is a fine balance between using other developers' code, and the lovely libraries designed to help fix your problems vs. finding your own solutions to every issue that you come across
Using other people's work may potentially hide issues that introduce more problems than you previously had. You don’t really know what you don’t know by using these magic algorithms
Writing your own code from scratch can equally create mistakes that could have been easily avoided let alone the time you spent trying to reinvent the wheel
So where does the happy medium lie? Maybe in a bit of risk management – check that the code you’re utilising has been written and optimised by a group or well supported and verified. This may not cut out all mistakes but will hopefully ensure that you’re largely covered
9. Never rollout/deploy on a Friday
The last thing you want to do at the end of a hard week is to make sure you've got everything spot on for deployment. If something goes wrong you've got to come into work and fix it or potentially meet a swathe of angry customers on Monday morning. There might not be anyone to console your customers over the weekend and your company may lose serious revenue and customer loyalty
Just don't put yourself through it!
Obviously, this does depend on the type of company and customers you work for but as a rule of thumb it is best avoided
10. Not looking after yourself
Most of us are guilty of being heads down in code and living on coffee and pizza and even energy drinks. You work late and just want to collapse on the sofa when you get home. Unfortunately, this isn’t sustainable – for your brain or body – go and get fresh air, some exercise and food that looks after you (as well as the pizza and coffee)
Don’t burnout – get in good habits now before it’s too late – you’ll be happier and more productive too
And remember - there is more to life than just writing code (but only just)