Rock Star Programmers - 5 Traits I See As Winners

In my heart, I’ll always consider myself a professional software developer.  I began writing code at the ripe old age of 12.  While I don’t write code on a daily basis anymore – the sin of being ‘management’ – I still write code at night to keep my skills fresh and to ensure that I can sit in a room with my development team and understand the conversation and hopefully add value.  While at one time, I considered myself an expert in the languages I used (don’t ask, they are all now ancient).  I realize now that I can still write good code – but because I don’t do it day in day out, I don’t kid myself in thinking that I’m the whiz kid anymore.  I’m not.  I’ve got team members that are extremely talented and I’ll give them praise any chance I get.

So what makes a great developer?

Over the years I’ve watched a lot of developers come and go in the shops where I’ve worked.  Some of these folks couldn’t code if their life depended on it and didn’t last long.  Others made it look effortless – producing code that was simple, easy to read and just seemed to work.  So what made these developers different, what did they do different than everyone else?

Patience

Some programmers get their assignment and without asking any questions start pounding out the code.  They’ll quickly listen to what is needed or skim the requirements and get to work.  They’re dismissive of further explanation, and are quick to say that they know what the users want better than the users of the system.

The best programmers take their time.  They actually read thru both the requirements documentation and the technical designs if they exist, or they’ll spend time interviewing the user to understand what the true problem is and what issue is being solved.  They are not only concerned about what it is that is wanted, but they take time to understand what isn’t wanted or needed in the solution.  These developers think not only about the specific assignment but want to understand how it fits into the whole puzzle.  Are there parts of the system that operate ahead of their piece – what do those parts of the system do to the data before it gets into the code that they are writing?  Are there parts of the system that will need the output of the code that they are writing?  How do they ensure that the data is validated before it leaves their code and is handed off to code written by another team member?

Lifelong Learner

Coasters – they drive me nuts!  These are the folks that think they know everything and that they are better than everyone else on the team.  They scoff at junior developers and will tell them that there is nothing that they can learn from such a junior team member.  The Coasters are forgetting that anyone can be a teacher.

On the other hand, I love lifelong learners.  These are the developers that are constantly pushing themselves to learn new technology, understand how to use the language they are developing in more efficiently.  They are constantly reviewing everyone’s code and are not afraid to take a chunk of code, walk over to the person that wrote it and ask them to walk them thru the code so that they understand what is happening.  They aren’t afraid when someone critiques their code and in fact actively pass their code around to others on the team to be examined.  When you run into them in the breakroom or walking thru the office, they will begin telling you about the new scripting language they are playing with or some new solution/tool/framework that might make the team more efficient.  Give these folks room to play – they will make your team better and find unique solutions to some of the toughest problems you have.

Commitment to Excellence

We know these folks – the developers that quickly write their code and then throw it over the wall for someone else to test.  They’re not concerned about what happens downstream – heck, they’re not even concerned about what happens within the code they just wrote.  They spend more time fixing their code than they spent quickly writing the code – in this instance, speed does not win the race.

Flip that around now.  The best programmers take their code personally!  They view their code as a direct reflection on themselves.  The best programmers will actually create their battle plan prior to writing any code – understanding exactly how they will test what is being created or modified to ensure that it works within the complete workflow.  Reviewing all of the incoming data, understanding what they should and shouldn’t expect.  Reviewing all of the output and integration points and understanding how the data can be manipulated and what are false values or boundaries of the data.  They will write small chunks of code or use scripts to test the code they are creating/modifying.  They are not only implementing unit testing, but are thinking through integration and regression testing along the way and then executing prior to handing off the code.

Passion

Look, if you don’t like your job – find something else to do.  We know these folks, they slouch in, plop down, ignore their fellow team members, don’t offer to help others, won’t bring new ideas to the table, won’t participate in meetings – team or otherwise and won’t do anything but exactly what they're told.  Are you kidding me!

Now, show me someone who is passionate about what it is they do!  Yeah, that’s the ticket!  I love these folks – they live and breathe to be the best coders out there!  They’ll call themselves a geek – and view it as a sign of honor!  They aren’t afraid to tackle the most complex parts of a project.  They find a way to practice their skillset – just like the best musicians.  If they’re given a particularly difficult task, they’ll try 2 or 3 different solutions to find the one that works best.  They are disappointed in themselves when they miss a deadline or someone finds a bug in their code – but they are the first to step up and take critique.  They view critique as a lesson along the way, will actually listen to it and attempt to learn from that criticism.  They will throw themselves at new technology when asked – and in a lot of instances without being asked – so that they can become more efficient.  You’re hired!

Self Sufficient

There are days I’ve pulled my hair out because someone will tell me that they hit a wall and couldn’t get any further.  When I ask them what the issue is, they tell me they’re waiting on answers to clarify some problem in the code or with the requirements/design.  When I ask them what they’ve done to solve the problem, I get a blank stare after they tell me they sent an email out 2 days ago.  Really, you couldn’t find it in yourself to stand up, walk to the other side of the building and get an answer?  Ugh – do I really look like I want to play baby sitter!

Now the best programmers are bull dogs!  They hit an issue and they are tracking down the best way to get the answer.  Sometimes that is tracking down someone internally, sometimes that is looking on the net to find a solution to a particular programming problem, and sometimes that is asking a team mate sitting a few seats away.  They are not afraid to ask questions and understand that communication can be used to solve issues!  If the issue is big enough, they don’t hesitate to escalate the issue – but usually have a couple of different options to resolve the problem.

Wrap Up

These have not been presented in any particular order, but they do represent the traits that I see in the best developers.  They are traits I attempted to show when my main role was to sling code every day and that I hope I still possess in the role that I currently play.

What are the traits that you see within the best developers you have on your team?  Let’s keep the conversation going!
 

If you'd like more information on my background: LinkedIn Profile

I Can't Find The Right People - Yeah Right!

I've had several discussions lately with different groups of people about hiring people.  I'm somewhat surprised at the attitudes of some of the decisions being made or expressed in these discussions.  Here are some of the comments I've heard:

1. We'll only hire people that have x years of experience.
2. We'll only hire people that can prove they have experience using xyz framework.
3. We'll only hire people that have a Bachelors degree,
4. We'll only hire people that have a Masters degree.
5. We'll only hire people that are experts in programming multiple languages.
6. We can't afford to hire newbies, it's too distracting.
7. We need programmers who also have experience as system admins?

Maybe we don't have a shortage of qualified applicants; maybe we're being too picky!  You want 7 years of experience, but you won't consider an applicant with 5 or 6 years of experience, really?  Someone can demonstrate that they know how to code and can discuss in detail their contributions to sophisticated development efforts – yet they don’t have a degree and you won’t hire them?  Your organization uses some hot off the press framework, or some framework that isn’t used by 90% of the developers breathing – yet you won’t hire a skilled programmer that has a track record of learning new languages frameworks and give them a few months to come up to speed?  You find a candidate that can develop is several languages – but is missing a key scripting language that your company uses, and you think that passing up this individual because you can’t afford to give them a little time to learn the scripting language – and this is a good idea?  You don’t want to hire new developers right out of college because you can’t afford to distract your staff – meantime, they’re working 70 hrs a week because nobody is there to handle the simple stuff or address the tickets being opened because of errors in the production environment, great choice!

As hiring managers, we’re supposed to be taking into consideration the long term needs and health of our teams.  I find these statements be short sighted at best.  Hiring inexperienced programmers into the organization provides several benefits that we need to be aware of and fight for:

1. They can take over the lower level complexity tasks that do nothing more than distract the more highly paid resources.
2. They can handle production problems that act as a distraction to the entire team.
• Side benefit – this forces these younger developers to learn the ins and outs of the systems that they are supporting so that they can transition into the development team at some point and take on more complex development tasks.

Part of the problem is we are relying on automated applicant tracking systems that filter out everything but an exact match with all of the keywords/buzzwords that we created for the job description.  These systems don’t allow us to find those gems that we can bring into the organization and grow into the next superstar.

How many times have you gone out and hired some superstar, just to have them leave 2 years later?  Sometimes these folks keep moving around because they know they can keep getting a bump in salary.

The real key is to understand the qualities of the people that currently work in your environment.  What makes them stay?  What makes them successful?  You then need to really hone your job descriptions to describe the type of people you want in the organization.  Then you need to adjust the applicant tracking system.  Stop filtering candidates out on skills and find ways to identify candidates based on the real traits you need in the organization.

If you’re a small company – do you really want to hire someone that has a track record of only working in large organizations and has a history of job hopping?  If you need developers that need to be able to meet with non-technical users – shouldn’t you be looking for a developer that has a track record showing that?

I’ll go further – sometimes you need to forget about finding someone with 5 years of experience and focus on finding an entry level programmer that displays a passion for learning, knows how to communicate, has local connections and will become the next rock star in your organization. 

Look at one point, none of us had experience.  Remember how excited we were when we got our first job?  Remember how we tore into any available documentation to learn?  Remember what we felt like when we moved our first code into production?  Someone, at some point, reached down, put their hand out and gave you a chance.  Now it’s your turn!


If you'd like more information on my background: LinkedIn Profile

Implementations - When Things Go Bump In The Night!

Sometimes bad things happen.  The question - how fast are you able to respond and put things back on track?

Technical teams need to plan and test their ability to rollback changes that are negatively impacting users.  This needs to be a formal part of your process - sometimes that means falling forward, fixing the broken functionality in production; sometimes that means falling back and reverting to a known state where the application was functioning properly.

Let's be honest - none of us are perfect all of the time.  Occasionally, we are going to miss something and move code into the production environment that ends up breaking things and making life miserable for the folks actually using the application.  

What have you done to prepare for this moment?

1. Does your implementation plan include steps to proactively monitor the system as changes are moved into production?
2. Does your implementation plan allow time for you to look at patterns of application activity to validate that you are not seeing patterns that would indicate that something is broken within the application?
3. Does your implementation plan include validation steps to ensure that the application is acting accordingly and that the new/changed functionality is working?
4. Does your implementation plan identify risk points and fallback strategies?
5. Have you tested your implementation plan?
6. Have you tested your fallback plan?

Every environment is different - but we mostly face the same types of challenges.  Breaking things that users expect to work is not what we want to do, but occasionally, it happens!

Yes, planning your implementations takes time.  Yes, planning validation steps and inserting them into the overall implementation plan takes additional time.  Yes, testing your implementation plan chews up more time.   And, yes, testing your fallback plan takes even more time.  That all being true, failing to do any of this means that your operating by the seat of your pants and your recovery time when things go bad will hurt you worse.

1. When your application fails - the reputation with your customers takes a hit.
2. The longer the outage increases the risk that your customers will walk away from you and begin to use a competing application?
3. Will an outage impact your revenue stream?

Now, all that said, sometimes even with all of the best planning, you're going to get caught.  It's bad enough when it's a web based application/service where you can make immediate changes or perform and immediate rollback.  However, what if it's software that you're sending out to customers - that they install on their systems?  How do you think Microsoft feels when they send out one of their regular patches only to find out that it causes the blue screen of death.  This can affect millions of computers around the globe.

Not to hit Microsoft too hard - but, in April they released a patch to Windows 8.1 that was required before any other updates could be applied.  This impacted retail customers as well as corporate customers and was not fixed until early May.  I'm sure that they ran their standard quality processes against the code prior to the initial release in April - but something obviously got by the testers, and it wasn't a minor issue.  It took time for Microsoft to hit the reset button, but in the meantime their customers were in an uproar.  

I'm going to walk softly here because as a developer it could happen to me or the teams that I lead.  I'm not trying to single out Microsoft - anyone that writes software has had to recover from a misstep when loading code into production or sending out a new release.  What I'm advocating for is that you implement solid processes that minimize the risk to your customers, your team and your organization.

What are you doing to mitigate the risk of an implementation/software release going bad?

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Languages, Languages, Languages ...

I speak regularly with High School and College level students promoting careers in technology - specifically careers with Applications Development, Quality Assurance and Project Management.  I enjoy interacting with the students and telling them what they may experience as they transition from the role of a student into the professional workforce.  Along the way, I also ask students to think about interning - either with my organization or some other organization in the area.  This is a fantastic opportunity for students to get real-world experience, become visible to an employer, and begin to understand some of the concepts taught in the classroom as they apply them to tasks in the workplace.

Many times, students ask me why we use the languages that we use and why we don't take advantage of the latest scripting or language fad.

My answer - why should I?  They seem to be stumped by my response.

Well, really, why should I?  Why should my team be disrupted on a regular basis just to use the latest language fad?  Why should I continually experience a productivity loss as team members shift between languages?  Why should I take the risk of bugs being introduced into production systems because the developers are not experienced with the language/tools that they are using?  Why should I risk customers being subjected to performance issues because the developers haven't figured out how to optimize the programs they're creating?  Why should I make the on-boarding experience for new developers more difficult?

Look, there are a handful of languages that we've committed to within our organization.  Four languages are used to generate all of our production level systems.  A couple of additional scripting languages have been used to create internal tools that assist us in production setup, as well as assisting us in ripping through logs to find specific information when we are researching issues in our environment.

Programming languages are programming languages - if you're a good programmer, you can pickup any language.  If you're a good developer, you understand that once you understand the various constructs of a language - learning a new language simply means translating the specific syntax of the language you want to learn to the languages you already understand.  It's translating how to use an if statement, a loop, a case statement, etc.  

Let's say it take you a month to become familiar with the new language - assume that your productivity drops by 50% and for 6 months after your initial learning period, you're running at only 75% productivity.  That means that over a 7 month period - you're productivity has cost the organization 8 weeks of development time.  Now multiply that across the entire team.  Assume their are 10 members on the team - that's a total of 80 weeks of lost development effort.  Assuming this same 10 member team and an average of 2 weeks vacation time for each team member - you have a total of 500 weeks that you can allocate to development efforts.  The end result is that you've stripped the team of 16% of the overall capacity of the team for the year.

Now, the numbers discussed above don't even take into account the impacts down the line as we move through test, implementation and post-implementation support.  How much more time will the Development Team need to create and execute unit tests?  How much time will the Development Team need to perform integration and regression testing?  How much time will the Development Team need to perform load testing?  How much extra time will the Quality Assurance Team need to test the application?  What additional issues will be experienced during the implementation of the code into production?  Can you quantify the number of additional issues that will be identified post-implementation that will need to be fixed and how much additional time it will take to address those issues?
 
The impact on productivity across the organization is significant and material - that is real time that prevents projects from being initiated or completed.  That's time that allows your competitors to either close the gap or get further ahead.

I don't mind taking on a new language when there is a need, or when there is a specific purpose.  Over the last couple of years, we've actually brought in specific tools that have allowed us to move in to the mobile market.  At this point, a select number of developers within the overall team have been exposed to these new tools.  Over time additional developers will be brought in to the loop.  Here, there is a specific need - our tools at the time did not lend themselves to creating cutting edge mobile apps.

Take a step back and look at the decisions being made within your organization.  There's usually a reason that organizations aren't moving as quickly from one language to another as developers would like.  To the developers that would like to get an organization to change - don't just go in and say that you need to be able to use a new language.  Document what you feel the benefits are, and just as importantly recognize the impact to the organization and craft your discussion points to address the costs that the organization will incur.


Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making;

For more information on David L. Collison: LinkedIn Profile

Sometimes, You Do Need To Break The Rules!

Well, it is all about the process, except when you need to forget about the process!

Quite the title … and an accurate description of what we all deal with on a daily basis.  There are some projects that come through the pipeline that don’t qualify for the full pomp and circumstance of the defined Software Development Lifecycle (SDLC).  Sometimes it is a low risk project, sometimes it is a project with a predefined date mandated by a client or a partner, and sometimes its just that everyone agrees what needs to be done and you just need to get it done.  Whatever the reason, we all have those projects that run through our departments with minimal oversight.

So, when this is happening to you, what is your reaction?  Many organizations just let it happen. Hey, the boss wants it, just get it done.  Right?  Nope, I’m here to argue for a process for the instances when someone says the process is getting in the way.

Ultimately, this is happening because someone in the organization feels that the formal process slows things down and that the need the team to be more nimble.  And, my response, yes.  If you make every project go through every phase and produce every artifact of your lifecycle - then it is going to slow things down.  The caveat - if you only look at it from the perspective of the first time through the cycle.  Typically, if you have a complex project and you begin skipping artifacts or lifecycle phases, you end up missing requirements, developing the wrong features, spending more time in testing or delivering a product into production with a higher level of defects.  Notice that I said, “complex project”.  The problem is that not every project that runs through your pipeline is complex.

So, what’s a team to do?  Strip down your process - identify the complexity and risk of the project at the beginning,  and make decisions on what can and cannot be left out during the various phases of the lifecycle.  Do you really need a discovery phase with it’s associated documents, or can you skip right to the requirements phase?  Do you need to create both a high level project design and a detail design, or can you skip the high level and just do the detail design?  Do you need to formally go through all of the decision gates, or can you just do the final gate prior to the project moving into the production environment?  Do you need to run in parallel, or will a regression test be good enough? Every project is different and for some projects you can simplify the process and reduce the churn and labor associated with the full SDLC.

I’m a huge proponent of creating a formalized SDLC process within an organization.  This can be waterfall, Agile, RAD or any other methodology that works for your organization.  That said, we can’t let the process get in the way of every project.  It’s not needed.  In fact, you may need to run waterfall on some of your projects and Agile on other projects.  I’m not here to tell you which process to use - just that you need a process and you need to be flexible in the implementation of that process within the organization.

I’ve had the fortune of creating the SDLC process for various organizations throughout my career. Small dedicated development shops, to larger teams spread out across multiple locations.  I’ve faced the same issues in every organization that I’ve been associated with.  At some point, someone higher up the food chain is going to make a commitment that you have to keep that will force you to break your process. Maybe that person will actually be you!  Will you just let it happen, or will you step back and optimize the SDLC for the specific request.  Once you do it, you will begin to find ways to make this happen on other projects moving thru the lifecycle.  This will show your team and management that you’re interested in making changes that improve the productivity and accelerate the development pipeline.

At one of my previous positions - I was constantly used as the example of someone who broke the rules.  Not in a bad way, but in a way that showed I was willing to change the status quo and find a different path to get things done.

What are you doing in your organization to streamline those projects that don’t need all the pomp and circumstance of your formal SDLC?

Tags: #SDLC #softwaredevelopment #lifecycle  #applicationdevelopment #programming

If you'd like more information on my background: LinkedIn Profile