The Dev Environment is Broken, let’s fix it
As a developer, it is too often that I have come across development environments that hinder the ability to develop rather than nurture it.
In truth, this is not due to a lack of available tools, most of which are free to use, but rather a psychological misnomer that investing in the developer environment is not a requirement as no end-user or client is ever exposed to this environment, coupled with developers simply accepting this as being one of the standard challenges of development.
The dev environment is very often referred to as a set of tools and processes used in order to produce software/hardware. While this is true, the crucial part missing here is the human touch and while tools and processes are most definitely a requirement, having an enthusiastic team to make use of those tools and processes is no less important. For me, my team is just as much a part of the dev environment as the tools and processes.
The idea behind this article is to empower developers with strong and rational explanations as to why their companies should invest more in their development environment(s) as well as why they should not accept this as a standard pitfall of development.
In order to truly discuss this topic, the first and probably most important thing to do is simply to set our egos aside for the next few minutes. This will allow us to assess from multiple viewpoints.
Different Points of View
Through the Spectacles of the Developer
As a developer, I want to be able to take pride in the work I do. I want to show off to my friends the latest features that I have developed.
My days are filled with daily standups, code reviews, peer assists, and many other non-development related tasks which in truth leave me very little time to actually do the job I was employed to do, take tasks created by a product manager and turn them into living features.
It’s really easy to throw blame around and explain that I couldn't reach a deadline for some reason or another.
The code is broken in the live environment but works perfectly when I tested it.
The build process took me several hours and failed during final compilation
My dev environment needed to be setup again as (choose a random technology) needed to be updated.
As a developer, I know that while these reasons will be accepted, most likely due to stakeholders not really understanding any of my tech jargon, these excuses are in no way responsible or acceptable.
Yes, yes, I hear all you naysayers in the peanut gallery and yes there are times where this could be legitimate, however, the illegitimate count far outways the legitimate and sadly renders them mute.
So as a developer, part of the reason I have been employed is to take responsibility and in some cases fight for what I require in order to provide the stakeholders with what it is they require, but most importantly in order to develop and be proud of the work that I do.
Through the Looking Glass of the Stakeholder
As a stakeholder, I am restricted by budgets, timelines, and employee work output. At the end of the day, I want my team to be successful so that I can be successful.
It’s more often than not that projects exceed the agreed and scheduled due dates and budgets.
In most cases, this is due to some technical reason that I don't fully understand and don't feel the need to understand as the dev team is made up of super professionals. But it really would be nice to deliver a project on time once in a while.
As a leader, it is my responsibility to ensure that my devs have all the tools that they require in order to perform at their peak. This means providing legitimate feedback on feature build time as well as providing features accordingly.
So obviously something is missing, maybe my expectations are too high!
Through the Eyes of the Writer
I have walked in the shoes of stakeholder, team leader, product manager, and developer and I can tell you navigating through these roles can be daunting and at times overwhelming.
But one thing to keep in mind is that as a team, we all have the same goal. If the team is not managing to achieve this goal it is the responsibility of every team member to assess, question, and provides potential solutions to where the problem may lie and how to resolve it… efficiently if possible… or granularly if not.
Having played all these roles, there are a couple of things I have learned along the way and I am happy to share them with you.
Your Team is More Important Than You
I’m sure you’ve heard this before and if you haven’t… then listen up.
Your success depends solely on the performance of your team and as such, your number one priority should be ensuring that your team has high morale, tools needed to do the job, and support from their manager.
Sounds easy! It’s not, but it's doable.
High Morale
How do you currently validate whether your team is feeling positive? How do you instill morale into your team when you see their drive to achieve starts to dip?
First things first, you may be the manager, tech lead, architect, or even “the best dev on the team”, but drop the ego and prepare yourself to have honest conversations with your team. While you may not agree with the team's feedback, you do need to consider it and act upon it. Be decisive in your actions but most importantly be humane and be respectful. Your team is not the enemy, don’t make them into it.
Now while this next section may seem like it is solely the team leads responsibility, it is in fact the responsibility of each and every member of the team.
Set your daily meet or standup (or whatever new word comes out to define it) after the team has had their first coffee after getting to the office. I know this sounds strange, but your team needs some time to get their brain juices flowing and you need to let them have it, everyone will be more productive. At the same time, every day. So if your team starts work at 9 am, then set the meet for 9:30.
I like to start my meet by letting each team member remind everyone what their previous day's goals were, then explain what they achieved and give a reason why, if any, they did not achieve their goals. Remember this is not in order to judge their ability, but rather to better understand what your expectations should be for each member of your team. This is the most valuable feedback as your team will be able to express what difficulties they face in order to deliver on time, and it is your opportunity to come up with solutions of how to improve this.
Being a part of the team as opposed to directing the team will allow you to have far greater insight into the emotional well-being and morale of your team.
Tools of the trade
You would never expect to see a surgeon go into the operating theatre and try to open up their patient with a steak knife they brought from home because the hospital does provide them with a scalpel.
So too in as a developer or manager, it is imperative to provide the tools required in order for the job to be done.
This starts at the most basic of providing hardware and software. For a web developer, this would be a computer and an IDE, for QA engineers this would be a computer and IDE and the required devices in order to run their tests.
Essentially each team may have different requirements but itis extremely important to express what you need in order to get the job done successfully.
For me personally, the most important tool is an unlimited amount of coffee which in turn gets processed into code ;)
Manager Support
The manager's role is to take responsibility for the team's failures and give credit for the team's success. Support your team at all times, find ways to help them overcome and improve.
Supporting your team doesn’t mean telling them what to do. It means being prepared to take on the challenges required in order to create the best working environment for your team. It means having to confront tough situations with your own manager and put the team's needs ahead of your own.
It means to juggle satisfaction between your team and your direct manager. It means being tough as well as understanding.
It means hearing (not just listening) to your team and your manager and creating acceptable middle grounds that lead to company-wide satisfaction and success.
Most importantly it means to be a decent human being with emotion, drive, and passion
If you find yourself with a manager that does not have these qualities, it may be time to speak with them, or even move on to your next challenge.
If you are considering promoting a developer to a team lead position take these traits into account and don’t expect them to be a “Yes Man”, and compliment on their drive to fight for their team.
If you are a developer that wants to move up in the world, consider that being the best developer does not mean you will be a great manager, these are two very different sets of skills.
