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

Don’t Be Afraid … Change!

Over the last several years, my teams have made significant changes to our project management, development, testing and implementation processes and paradigms. We’ve had some bumps along the way and in no way do I consider this evolution over. I will continue to challenge my team members to find a better way to build the mouse trap that drives our software development lifecycle.

Let’s look at some of the successes the teams have had introducing change into the organization:

1. Our project management process used to be split into separate and distinct teams: 1) project management for business and operational teams; 2) project management for technology teams. This has been consolidated into one project management team managing all project related activity across the organization. This has streamlined activity and improved communication across all teams involved in the process.
2. Our lifecycle was revamped as we consolidated the project management organization. During the revamp – we created RACI documentation that clearly outlined 1 owner for each key task/milestone within the overall project activity, along with those that would act in the roles of responsible, consultative and informed parties. This has provided clarity to who owns each activity and what the key tasks are that are included within every project.
3. Recently we made additional changes to the lifecycle – completely eliminating 1 phase and adjusting the tasks and milestones associated with both our scoping and design phases. This has allowed us to streamline the process and give clarity to when project activity actually starts within the organization.
4. We have challenged all of our team members to review the overall standard tasks/milestones within any given project, and challenge the project manager and sponsor to eliminate tasks and standard artifacts when it is justified and where there is minimal risk associated with utilizing an altered process.  This decision then is documented as part of the project and communicated to the team to ensure that down the road, people can review the effort and understand why certain documents or tasks might not have been done. This should allow us to be more nimble and find the best path for each project to take thru the organization.
5. A couple of years ago, it took up to 3 weeks to complete regression testing associated with key functionality within our application silos. This was a manual effort that typically was handled by multiple individuals. The teams have worked hard to automate the regression tests associated with these applications. Today, the execution of these tests can be done in less than 17 hrs. The labor savings moving forward will more than pay for this effort. This also allows us to provide quicker feedback to the development teams and ensures that our regression testing is more consistent across all projects.
6. Recently, the teams also completed the resurrection of standardized test data to be used across our test and development environments. This will be further enhanced as our automated tests are enhanced to create/modify/cleanse and reset data needed for a given test. This will reduce the time spent creating test data for each project and will ensure downstream processes/applications have the data that is needed to execute their regression tests.
7. Over the last several years, our implementation plans have seen significant improvement. Our business demands that our systems be available 24x7x365. When you want to buy a tank of gas at 3AM or 3PM, you want the transaction to go through so that you can continue on your way. You would not find it acceptable for us to deny the transaction because we are updating our systems.  Our implementation processes have been templated and include all implementation activity, across all application and infrastructure silos, commands, scripts, validation and fallback steps in the order they will be executed.  Recently, our external auditors informed me that our implementation plans are among the best that they have ever reviewed. This has hardened our implementation activity – reducing the overall time needed to implement changes into our production environment, standardizing the validation activity during and after implementation activity has occurred and most importantly having fallback steps at the ready when any validation activity shows that there may be an issue.
8. Our development teams have changed their processes to include code reviews of all changes prior to those changes being introduced into our production environment. This is hardening our code base and reducing the risk of making changes within our production environment.
9. Our development teams have changed their processes to ensure that unit tests are created for all code being touched within a project.  These unit tests are then kept in a repository and used in future projects. This, again, has hardened our applications and reduced the overall number of bugs slipping through the process into our quality assurance testing or into our production environment.
10. Our development teams are now doing nightly builds – with reports going back to each team on build failures, unit test execution failures, code coverage and other statistics. This is giving immediate feedback to our development team and ensures that issues are addressed within 24 hours.

These are just some of the changes that have been implemented by the teams over the last several years. And we’re not done! Moving forward, we will move the regression testing into our nightly build process. We will be evaluating further changes to our development lifecycle to reduce the amount of time between idea generation and product introduction into our production environment. We will continue to improve upon our implantation planning. We will introduce key metrics across the development lifecycle. And where it makes sense, we will introduce Agile techniques into the development process.

I talk to college and high school students on a regular basis to discuss what it means to be in the technology field (specifically software development). The one constant that I tell students is that being in this field means you will constantly have to learn. They will learn new languages, they will drive change into the organization, they will experience multiple different development paradigms. All of this is good – it means the organization is alive, is learning and is adapting to its competition. 

Don’t settle for how it works today or with someone telling you, “well, that’s the way we’ve done it for decades!” Your job, no matter what role you play in the organization, is to find a better way, review your suggestion with those that can help implement, trial those changes and then roll them out across the team and the organization. Change is good – don’t settle for the status quo! 

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

Don’t Hide Behind the Process

Well, it’s been a while since I’ve discussed process issues.  Time to dig in and have some fun!

Most of you that have followed my previous posts know that I’m a process kind of guy!  I’ve introduced formal lifecycle management into several organizations.  The teams that I’ve led have successfully utilized process enhancements to drive improvements in productivity, overall capacity and quality within various organizations large and small.  Utilization of a known process allows you to begin to measure various pieces of the lifecycle – looking for inefficiencies and issues that impact your overall ability to deliver for the organization.

Now all that said, each organization needs to find the lifecycle process and development paradigm that will work with their culture.  I’m not going to try and tell you what development paradigm you need to follow because I don’t know your organization.  Within the organization I currently work for we largely follow a waterfall process with some agile techniques utilized within various teams.  This works for us and the style of applications that we create/support – mostly technical interfaces within the payments industry.  Our overall lifecycle has various checkpoints/gating that we use to validate we are ready to move to the next stage.  This works for us!  We’ve significantly increased our productivity and capacity over the last decade and have improved the overall quality of applications that we are delivering to our production environment.

While all this has been good, I occasionally notice when people are hiding behind the process versus just getting the work done!  Not every project needs every step of the lifecycle.  Some are small enough and straight forward enough that we can skip various parts of the process or make the decision not to create some of the standard artifacts/documentation.

Decisions need to be made up front when the project is defined.  Those in the know, need to direct the teams when a project needs the full pomp and circumstance of the lifecycle and when the teams have the option to skinny up the process and skip parts of the lifecycle.  That means at the very earliest stages of Discovery, the Project Sponsor should be giving direction to the team on what the risks are associated with the project which can then drive decisions on how much of the process can or should be used on the project.

Additionally, once a project has been initiated, I think individual team members need to be cognizant of what is happening and make recommendations to the Project Manager if they feel certain pieces of the lifecycle could be skipped or maybe some documentation might not need to be created.  I’m not saying that we’ll always make the choice to skip over pieces of the lifecycle or to not create various pieces of documentation, but as leaders, we need to listen to the recommendations of the people closest to the work and if it makes sense, say yes!  When we decide that we can skinny up the process used within an individual project or that we can eliminate some of the standard documentation, those decisions should be documented.  That way, there is a record of the decision and the reason is documented and shared with the Project Sponsor.

Overall, we still need to deliver for the organization!  Delivering the requested solutions with the necessary features/functionality; delivering a solution at or below the expected budget; delivering a solution with the highest levels of quality.  Our teams should be held accountable to ensure we are delivering successful solutions at the end of the project.

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

Plan for Success ... Be Aware of Reality!

I run hard! My teams run hard!  We’ve got a lot on our plates and the pipeline is overflowing.  As soon as something is done, there are 5 more things waiting in the wings that need attention.  That’s a good thing – it tells me that the business values the services that my teams deliver on and that we can continue to be a difference maker within the organization.

As we go about our business – we plan for success.  Delivering product and services that our Financial Institutions can use to succeed in the market and make a difference with their customers.  Over the last several years, we have built a process around activity that ensures that we know why we are building something, we know the success factors around what it is we are building and that we then can design, build and QA the stuff we are moving into our production environments.

The teams have done a great job of reducing the number of iterations built before code can move into production.  Translation, they’ve reduce the number of critical errors found during testing that requires additional iterations prior to implementation!  They’ve also significantly reduced the number of issues that require after hours support.  Our teams have worked together to reduce the overall amount of time needed to regression test our products.  We are doing automated nightly builds on our code and are well on our way to having a full suite of regression tests run along with the automated builds.

So why am I talking about all of this?  Well, to put it all in perspective, it doesn’t seem to matter how well we refine the processes and manage the activity, we still have things go wrong!

1. Requirements identified after development is under way. 
2. Designs between teams that sometimes conflict. 
3. Estimates of project activity that end up being woefully incorrect. 
4. Resource constraints across teams just based on the sheer volume of activity. 
5. Data issues within our test environments. 
6. Validation exercises that end up taking longer than planned.

You know the drill.  You’ve all seen similar stuff happen to your projects.  So what’s a team to do?  Well as much as we want to keep our rose colored glasses in place and see sunshine and rainbows, it’s our job as leaders and technical experts to measure and apply a dose of reality within our projects.  The organization is looking to us to deliver new features/functions into the production environment.  They don’t really care to hear about how we make the sausage or why it might be taking longer.  What they do want is a semi-reasonable date as to when the features/functions will be available and what it means to our Financial Institutions and our Acquirers.

So, translating back to our internal teams, that means we need to make reasonable estimates along the way and refine as we move through the process.  As technicians, looking at and identifying the tasks needed to complete the activity – you can’t assume everything will go the way you want and your estimates need to include the breathing room you’ll need when something unexpected pops its head up.  As project managers, you can’t believe everything you’re being told – you need to validate what is being said and ensure people are on track.  Depending on the complexity of the project, you may need to put in some buffer time between the various activities to ensure that the teams have time to stay on track and recover from unknown issues.  This may not be needed on smaller less complex projects, but as the complexity gets bigger, you’d better start thinking seriously about buffer space.

I am not advocating that you needlessly pad time into your projects to make a 6 week effort end up taking 10 weeks.  What I am advocating for is that project resources accurately evaluate their tasks in a realistic fashion and feed those numbers back up to the project manager – that includes identifying the riskiest tasks and ensuring that you’re not being overly optimistic on the estimates.  Additionally, the project manager needs to review those estimates coming in and ensure that the numbers are ‘good’ and make judgements on where additional time may be needed to address parts of the process that look to be difficult.

I’ll give you a perfect example within my own organization.  With our large enterprise wide projects, we perform an integration test within development prior to moving the code into our formal QA and Parallel environments.  We began this formal ‘integration’ test effort probably a year and a half ago.  This testing required us to ensure mock data was setup across various platforms and application silos that would allow us to take transactions across the entire ecosystem.  This was initiated to ensure that by the time the code hit QA that we had successfully tested input/outputs and application handoffs between the various silos.

When we initiated this new step in our overall lifecycle – we were extremely aggressive in how long we thought it would take us to build the environment, populate the environment with the correct data and then execute the integration test plan.  I kept pushing the team to get all this activity done within a short time window so that we could then get into the ‘real’ testing and move the project forward.  Whether planned or not – the time associated with this integration testing took longer than planned and we eventually had to account for that within our planning.  Now that we’ve been through several iterations, we are beginning to automate various pieces of the environment and data setup/configuration – this should help us draw the time back down

Our goals were right, this helped us implement code into production that had a higher level of quality, however, I created a set of false expectations within the teams on the durations associated with this activity and they needed to give me feedback to reset my expectations and identify the correct timeline within the overall project activity. 

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

Logic and Project Management!

As a child, I was glued to the television whenever there was an opportunity to watch Star Trek!  I loved the show - campy by the standards of today, I couldn't help myself as I wanted to be on the Starship Enterprise as she traveled to the stars.  And, yes, my favorite character was Spock - followed closely by Scotty.  Spock in may ways spoke to many of us - using logic instead of emotion to solve problems.  And when he did let his emotional side out of the box - showed that emotion could and would frequently lead to painful mistakes.

So, why am I using space within a blog focused on project management and applications development to discuss Spock?  Logic - use it to succeed within your role.  Strip aside the emotion that you feel when confronted with issues and follow the facts!  Stay calm, track down the details and use those details to identify the move forward solution.

No project of any realistic size moves from idea to implementation without some sort of issue rising up, ready to take the whole thing off the rails and into the ditch.  Some problems are small and others tend decloak themselves like a Klingon battle cruiser to surprise and fire upon your Starship Enterprise!  These incoming salvos threaten to overwhelm you, the team and the project.  At this point, you can either act emotionally, running around without a plan and make the problem worse.  Or, you can act like Spock - use logic to create a plan, execute the plan and overcome the issue.

Planning:

Sometimes with a small issue, you can 'wing it' and successfully manage the issue.  That said, the larger the issue, the more likely you will need some type of plan and process to deal with the issue.  Leadership in the organization is going to expect you to communicate the issue, progress in finding a solution and then progress against whatever plans are ultimately put in motion to resolve the issue.

There will be wide variety of additional items you will need to manage within the overall effort:

1. You may need to setup a research team to investigate how the issue was missed or what the cause of the issue was so that this information can be communicated to the management team.
2. Additional personnel resources beyond the original scope of effort associated with the project to identify the overall solution as well as assisting in any work needed to implement the solution.
3. Additional budget resources beyond the original scope of the effort to cover any additional internal or external resources needed to provide the overall solution.
4. Communication plans may need to be put in place to update internal resources, communicate with and manage customer expectations and manage any risk to the overall reputation of the organization.

Each of the above items will require management effort from the Project Manager to ensure that future milestones within the overall effort are adjusted and manged properly; and to coordinate activity between various team members, departments, and outside consultants.  All of this will take careful planning, using organizational skills to minimize the impact to the project.

Methodical:

Many times as a Project Manager you are dealing with choices - making decisions about where short-cuts can be taken; making decisions on whether to go with Plan A or Plan B when there is no consensus from the team on which direction to take; sometimes sifting thru agonizing amounts of detail to understand an issue so that it con be communicated to the management team.

As the complexity of a problem increases, the number of details being tracked or managed associated with the issue will grow beyond your minds ability to track them all.  You are going to need processes in place that allow you to align the issue resolution within the overall tracking mechanisms in place to manage the project.

1. You will need to track new data points within and aligned to the overall project - new milestone dates, budget information, new internal and/or external resources, new equipment that may need to be purchased.
2. You will need to realign your current schedule to accommodate any new milestones associated with the new effort.  Especially those new milestones that will require current or future activity within your plan to be delayed or altered.
3. You will need to ensure that communication plans are executed properly not only to manage internal expectations, but just as important to ensure that customers, vendors, the media and other 3rd parties are kept in the loop.

Your role as Project Manager requires that you have a plan, that you execute the plan and that you manage the expectations of your team members.  You need to be the calm within the storm.

Detail Oriented:

Team members are going to be hitting you with lots of information - your job as Project Manager is to sort through the minutiae and ensure that the relevant data is recorded, tracked and used to make decisions throughout the overall project lifecycle.  As Project Manager, you will be expected to identify the important pieces of data, communicate that to the team and ensure that the information is available within meetings as decisions are made on the forward progress of the project effort.  

Additionally, management will expect that you understand the relevant pieces of information within the flood of details and know when to present that information up the ladder.  Many a Project Manager or Manager have failed when they have forgotten to keep the leadership team informed on decision points and the underlying information used to make those decisions.  I'm not saying that you should have the expectation that your being micro managed - but when there is an unforeseen issue that crops up, over communication is necessary to ensure that everyone understands the nature of the issue, the solution being implemented and the overall impacts to the organization.

Logical:

You can be angry and frustrated - that however is not going to help you move the ball forward and find a solution.  At this point, you need to step away from your emotions and use logic to understand where your at, what data points you have available to make a decision and then make short and long term decisions based on that information.  Knowing that you can adjust future activity and decisions based upon additional data points that surface.

Spock would 'follow the facts' to get to the answer - wherever those facts happened to lead him.  That's your role!  You will be tempted as angry and frustrated team members, management, customers or 3rd parties call you or come over to talk with you.  At times, you will want to 'fire back' at the individuals - however, it is better to step back, take a breath and then approach the conversation.  Focus on the fact, just the facts!  Use logic - it is the best tool you have at your disposal to deescalate the situation.

Mr. Nimoy, you are and were an inspiration to many of us ... may you live long and prosper among the stars!

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