Reading the headline quote of the famous Christmas song by Mariah Carry, you might be thinking – talking to me? Well… if you are passionate about what you do, if you are genuine interested in making a difference with your work and always put the team first, it might be you I am looking for. If you are a director, manager or in a similar position and thinking it might be you, I am sorry to disappoint you – it’s not you.
The person I am looking for is someone who delivers actually deployable value to the users; someone capable of making a difference by transforming an idea into a valuable feature in production. That’s right… all I want is you – the Agile Developer.
We have worked together in the past and you have never disappointed me. Often you have told me what I didn´t want to hear, but I have learned the hard way to appreciate your honesty. I have come to love your energy and professionalism and I have come to understand that your actions are always based on a clear vision of the overall objectives. More specifically I truly value the qualities in you I have listed below.
1) You work for outcomes
The outcome of the project is always your top priority. When the team has a problem, you don´t waste time assigning blame or worry about credit, but focus all your energy on fixing the problem. Instead of pointing fingers you point out possible solutions.
2) You don´t take shortcuts
You know that a quick fix clutters the code and makes it less visible and readable. You don´t fall for temptation of taking a shortcut, but invest energy in keeping the code clean and out in the open.
3) You criticize ideas, not people
You know that we are all capable of generating great ideas and you don´t want to discourage anyone from speaking their mind freely on the project. You know that their next idea might be the brilliant solution we are looking for to move the project forward. You are good at pointing out possible improvements or pitfalls in a suggested solution not taking into account who originated the idea.
4) You are brave and speak your mind
Sometimes you realize you are heading down the wrong path. You know that continuing is not the best option and you are brave enough to tell the team. You know that your bravery might have serious consequences to the project timeline and budget, but you know sharing with the team is the right thing to do.
5) You know there is nothing permanent except change
Even if you have become an expert at a certain technology you know you will be overhauled if you do not keep up with where the industry is heading. You are not spending all your time becoming an expert at everything, but you spend a little time regularly catching up with the latest development to keep you top of your game.
6) You not only invest in yourself
In the areas where you or someone else on the team is knowledgeable you try to help the rest of the team catch up. You might arrange a weekly tech-talk lunch, where the team eats together and discuss a particular topic.
7) You know when to unlearn
As you gain new knowledge you know when to let go of old technologies and habits. You are careful not to project too much of the old way of doing thing onto new technologies. Instead you try to reinvest your experience and apply it in new ways that fits the new technology.
8) You keep questioning until you get it
Sometimes you can be a pain in the butt. You keep asking questions until you fully understand the reasoning behind decisions and designs. Often your questions lead to a deeper understanding for both you and the person answering your question because you don´t settle for anything less than the root cause.
9) You feel the rhythm of the project
You can feel the rhythm of an agile project like you know your favorite piece of music. You take pride in finishing a task and checking in the code on a daily basis and you strive to meet the iteration deadline. You focus on delivering minimal, yet usable and valuable to the customer, chunks of functionality at the end of iterations.
10) You present customers with alternatives and let them decide
Whenever you are in doubt what to prioritize or how to implement a specific feature you involve the costumer and let them make the decision. You present them the different options from a business perspective and explain them the cost, pros and cons.
11) You only let design guide, not dictate
When starting a new project you know better than trying to design every detail upfront. You do enough design to be confident that all major angels are covered and you are not afraid to change the detail as you start implementing the solution. You know that your understanding of the requirements will evolve along with the code.
12) You justify technology use
Although you find new technologies exiting you never pick a new technology for a project without determining the needs of the project first and evaluating the possible pros and cons of the new technology.
13) You always keep the code releasable
You know that not integrating code early and regularly is a risk to the project and your code is therefore always compilable and runnable. You always get the latest version, compile and run the tests locally before checking in new code in the source repository. You point it out immediately and offer to help fix the problem, if you find out that a build is broken or a test in the integration server fails.
14) You value customer feedback early and frequently
You know that the business of the customer is constantly changing and that the customer themselves change their mind about requirements frequently. You therefore value frequent demos where you can get feedback on implemented features and discuss and adjust features to be implemented in future iterations.
15) You value automated unit testing
When developing in small increments you are constantly refactoring existing code to fit the current requirements of the solution. You know that writing unit tests before writing the code itself and keeping your tests running cautiously is the only reel way of making sure that solving a problem in one area doesn’t introduce a new in another area.
16) You know that different makes a difference
When writing and testing your code you know that even the smallest differences make a difference. If your code must run on different versions of the operation system or in different client browsers, you carefully test the code in the different versions to make sure the code is not affected by the differences.
17) You communicate in code
Code readability is a priority for you and you always prioritize it over convenience. To you code is just like any other language. When you pick names for a class or method you try to find a name best representing the behavior of the code inside. You carefully select the names of variables to make it obvious to the reader what information it contains.
18) You evaluate tradeoffs before making a decision
History has taught you that there seldom is only one solution to a problem, but often multiple solutions with different pros and cons. You carefully evaluate your options and pick the solution that has the most pros and least cons.
19) You always develop in increments
You develop in short cycles focusing on tackling one problem at a time. You never code for hours nonstop without stopping to make sure you are on the right track. You constantly look for ways to improve your code while reading and you use the tests frequently to get feedback on the code you are writing.
20) Your code is simple and cohesive
You are not impressed with page long printouts of single methods. You know that complicated code can turn into a monster in second and is often hard to debug. You keep your code simple and you keep your classes focused and your components small.
21) You treat warnings as errors
You never check in code that compiles with warnings since it’s not problem free code and therefore not the quality you want to be associated with. You might be tempted to check it in, but you know that warnings are potential problems waiting to happen.
22) You attack problems in isolation
When working on complex solutions you know that finding the root-cause a problem can be very difficult because of all the possible influencing factors. You isolate the problem area from its surroundings when trying to locate and fix the problem. If you can’t isolate the problematic code from the rest, you invest time in writing a prototype to isolate and find the problem.
23) You know to expect things go wrong
You not only think through how the code should work, but also what happens when it doesn’t. You make sure all exceptions are handles or propagated. You know not to catch and ignore an exception, even temporarily, to keep the compiler from complaining. You know that these temporary hacks are often forgotten only to cause problems later.
24) You know the code belongs to the team
Developing complex solutions require collaboration and you know that any team member who understands a piece of code should be able to work on it. You don´t keep code exclusively and you appreciate being rotated across different areas of the solution along with the rest of the team, because you know that the overall knowledge and experience level of the team benefits by it.
25) When possible you take on the mentor role
When you find yourself being more knowledgeable about a particular subject, like part of the system or a specific technology, you willing share your knowledge with others. You know that knowledge sharing takes noting away from you, but often lead to both you and the recipient gaining more knowledge.
26) You allow others to also figure it out
It goes without saying that you are a great mentor and has plenty to share, but you are careful not to just solve the recipient’s problem. You know that they will learn a lot more from figuring out the solution themselves, but you are more than willing in pointing them in the right direction or giving them a gentle push when they get stuck.
27) You never share partly working code
Checking in partly done work into the source control system can slow down the rest of the team, if they check it out before it’s completed. You always make sure the code you check in is in a steady state, compiles, passes its unit tests and is readable to the rest of the team, before you check it into the source control system.
28) You participate in code reviews
You know that the best time to find problems in code is just after it was written. You enjoy participating in a continuous reviews session (pair programming) or formal code reviews because you know that it will improve the overall quality of the solution. When reviewing other developer’s code you make an effort understanding their implementation and of giving constructive feedback.
29) You keep others informed on progress
You know that accepting a task, you have agreed to deliver it on time, but you also know that running into problems during implementation is not uncommon. When you do, you inform the rest of the team, just like you do when you find a neat solution to a complex problem that will benefit the hole team.
30) You remember to have fun
Developing complex software solutions is serious business often taking all the effort the team can mount to be successful. You take the challenges seriously, but you also remember to have fun in the process and to celebrate the team’s victories.
Merry Christmas,
Martin
This post was inspired by the great book Practices of an Agile Developer by Venkat Subramaniam & Andy Hunt – A must read for any developer working in an Agile environment or looking to make the transition to Agile.
Image credit: Unsplash.com
