At the end of a mentally draining day fixing bugs, angry clients and tight deadlines, I can honestly hold my hand up at times and say that my work has made me into a stressed developer. Sometimes I wonder why I even do it. I accept, like any job, sometimes things just don’t go to plan. And I believe that in most digital agencies, the buck stops with the developer(s) involved. Here are some of my thoughts on getting through those bad times, without the alcohol or swears.
1. Don’t bite off more than you can chew
It might be tempting, especially as a freelancer, to take on any work categorised as ‘web development’. However, if you don’t have the experience of a particular discipline, you’re just setting yourself up for more work and unnecessary stress. I talk about this in more detail in my article: Advice I Should Have Paid Attention to as a Freelance Web Developer.
I found myself in that situation, with an e-commerce site, in my early days of freelancing. It was a project for a shopify store, something I’d never used before. But in my arroganceI was like, ‘ahhh it’ll be fine, the docs say that it’s EASY…’ It soon became a headache when the client wanted more bespoke amends. In the end it became too much and I ended up outsourcing it to a more experienced developer, do the dismay of my profit margin.
Work out what your skills are, and stick to them. If you’re going to be a shopify developer, commit to it 100%. Learn your skill in that niche and specialise. Stay in your lane when it comes to working with clients. Only bring new skills to the table when you’re confident enough to put money on it. This is one way to become a less stressed developer.
2. Make it a learning experience
So I’ve said to avoid areas of work where your skills are weak or non existent. Now ignore that advice. Confused? Let me explain …
Sometimes you might find yourself working on a project with no prior experience of the platform it’s on. Imagine a new platform that your company has taken on board.
Some in house developers know of it. “You know nothing“, to coin a well known northerner. Google that phrase, I dare ya.
However, your company would like you to apply your front end development work to it. That’s the situation I found myself in with Drupal.
Learning on the job
It was part of a company aquisition. We’d inherited some Drupal developers as well as some clients with Drupal websites. It was only a matter of time before one such project came my way. I’d never worked with Drupal before, and I soon realised that front end work in it was unlike anything else I’d worked on previously. I was but a lowly developer with the task of applying the skills I was comfortable with -front end development- and applying them to a predominantly back end/PHP orientated platform. Joy.
To be a less stressed developer, my only chance I had was to treat it as a learning exercise. No training was provided. The ethos of my company was pretty much figure it out yourself. This was both good and bad. Good in that, they’re aware that development might take longer (budgets were generally massive for Drupal) but any learning had to be done on the job.
So I ended up pestering the back end developers quite a bit. I had a lot of questions that were answered quicker than a Google search. I found the Drupal official documentation a little hard work to make sense of.
Honesty will see you through
You may find yourself in a similar situation. In that case, be honest with yourself. Be honest with others around you that you lack the experience, but you’ll do the best you can. You may very well get the support you need, such as another developer, or time for training. I was lucky in my role. My company understood it was quite an undertaking, realised I was a stressed developer. Though I wasn’t offered training, I was given the time to wrap my head around the Drupal workflow.
It’s a mistake that many businesses make. A web developer can’t just pick up anything and just ‘do the code’. That kind of stress shouldn’t be yours to bear. If they’re aware of your position, it’ll be fine if you make mistakes. Don’t worry about it and focus on the learning!
3. Forward planning is king
Strategic pessimism, or defensive pessimism, should help you to mentally prepare for any kind of outcome. It’s actually a thing I overheard recently, so I googled it, and found something quite interesting. It’s a frame of mind to expect things to go wrong, but without really paying attention to the negativity it brings. I worked out that I actually do it without thinking!
For example, you have to put a website live. You’re also responsible for deploying it from staging to test. You’ll need to make sure your contact forms still work, any test and debug code has been removed, check links point to their correct location, you don’t have 404s being returned for assets, and make sure the whole thing just doesn’t break horribly.
I’d expect one or more of those things to go wrong, and plan for it. Remember the mantra, “be a less stressed developer”.
If you’re replacing an existing site with a new one, there are some other things you’ll also need to account for. Expect the worst, and you’re prepared for it even if it’s actually unlikely to happen.
4. Be open to suggestions from others
Sometimes a problem to a solution will come from unlikely places. It’s at those times it’s probably better to swallow your pride and take those ideas on board.
Be humble my friend.
You might even bounce a better idea off that, and come up with a solution. The point is, you’ll inevitably run into problems with coding that will stump you. Or bugs and other problems that you’re really not quite sure how to fix. I’ve had a few of those… so walk away from the keyboard for a bit, do something else.
There might be another way to come up with a solution, a workaround or different approach to what you might want to achieve. It’s easy to get stuck in a rut and let time run away from you, as you’re trying to work out how to fix the problem in front of you. If you’ve got other developers available, it’s always useful to get a fresh pair of eyes looking at your code. And sometimes you’ll just have to stick in a temporary hacky fix, and solve it for another day. Such is the life of a developer.