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!
Sometimes I'm left surprised when an issue hits my desk and I begin to work backwards to find out what happened. In too many instances, I can trace it back to follow-through. Someone in the organization knew something, or was assigned to do something and for some reason forgot. What's even more irritating is when I'm the guilty party!
Recently, I was rightfully called out by one of my peers for not communicating a decision impacting a critical project out through the organization. She had every right to call me out on the lack of communication. It was my error and I could do nothing but agree with her and acknowledge the failure. I like to pride myself on the fact that have strong communication skills and working relationships with my peers, and so I take this one personally. There are many excuses that I could use - I'm too busy as we move several key projects into production ahead of our year end production freeze; the Project Manager should have communicated that out to the team. Ultimately, I made the decision and I had the responsibility to communicate the decision across the organization - especially when that decision was going to put pressure on other teams across the organization.
This is not unique to myself. As I began to explore at the beginning of this post, too often I look at the root cause of an issue and it all goes back to someone knew and didn't think to share that knowledge.
I recognize that some of this is human nature. In the heat of the moment, decisions will be made that we believe will move the process forward and get the entire organization closer to the end goal. While that may be the case - follow-up is critical. Let's face it, we've all sat on the receiving end of some decision that made our lives miserable. We've had to deal with the fallout when that information comes at the last minute. I will be the first one to step up and call someone out when they do that to myself or one of my teams - it's only fair that I take the feedback when I'm the one causing the problem.
To allow this type of honest feedback - you need to be willing to trust the teams you work with on a daily basis:
- Your direct reports
- Your peers within your supervisors team
- Your peers across the organization with whom you deal with on a daily basis
One of the best books that I've read on this topic was written by Patrick Lencioni, "The Five Dysfunctions of a Team".
This book leads you through a scenario of how a group of individuals that didn't work or trust each other was transformed into a highly functional team.
I was first introduced to this book, by my current boss - our CIO. It was the first thing that he wanted me to read after I was hired. In fact, he sent it to me before I even officially started. It is now one of my favorite books. I in turn have required all of my direct reports to read the book. I encourage my team to be honest with each other and to hold each other accountable in their daily interactions.
We have been hired for a purpose. We are here to make a difference, to move the ball forward. That means holding ourselves and others accountable for the deliverables that people throughout the organization rely on so that they can do their job. We must open ourselves up to others, understand the story that is driving their actions and be prepared to receive open and honest feedback when we fail to live up to our commitments.
Don't get me wrong - this isn't a directive for you to walk around the building pointing fingers at people and telling them they're not doing the job - chances are if you did you'd have a line of people at your desk telling you that you didn't do your job. What you should do is be willing to engage in a positive open communication. Explain what you are seeing - you may not have a full understanding of the situation and be prepared to change the direction of the conversation based on what you hear. If the person truly is responsible for failing to deliver, than it's up to you to find a positive way to work with the person and manage the situation. Help them help you!
If you'd like more information on my background: LinkedIn Profile
When I got my first professional job - it was selling IBM PC's and
compatibles, along with the assignment of teaching a couple of courses
for the company I worked for - these courses included dBase III and I
believe Lotus 1-2-3 (that should give you a pretty good indication of
how old I am). Yes, I had done contracting work prior to this job - some
coding on the IBM 5110 - which was state of the art at the time. But
that wasn't full time and I fit in the coding between school activities
and my real job.
After a couple of years, I sought to find a job
doing software development - I learned that although I could sell, I
didn't like it. I also knew that I really enjoyed programming. So the
switch was logical. Looking back on those first two jobs, I realize that
although I thought I knew everything, in all honesty, I barely knew the
basics. Following are some of the things that have been ingrained into
my psych over the years – things maybe I knew, but didn't realize were
important when I started my professional life:
1) Patience is a virtue. I've indicated in previous postings that I'm a Driver - with a capital D - learn more by reading about Social Styles.
That's not a bad thing, it's not a good thing, it just is. My
particular issue - one that I've learned to manage over the years - is
that I want to dive in head first when I see a problem. What I've
learned over the years, is that in many instances, you want to listen
and ask before starting to solve a problem. In fact, I frequently tell
my direct reports that when presenting me with a problem, they need to
let me know: 1) they just need some room to vent; 2) they want my input
on ideas on how to resolve the problem; or 3) they are escalating the
issue and want my involvement. I had/have a nasty habit of jumping in on
their conversation and telling them how to solve the problem. In many
instances, they don't want me to solve it, they want me to guide them
through the process and help them solve the issue (some might call this mentoring).
2) Be Passionate about your Role.
I can honestly state that I've loved most every job that I've ever had.
I've never left an organization because of the work - I've left
organizations because of the culture and because of specific
individuals. If you want to get ahead in your current role, you need to
show passion, you need to let your boss know that you want to help
him/her. Volunteer for the tough assignments! How many times have you
walked up to your boss and asked if there was anything on their plate
that you could help with? When an opening has occurred, have you ever
told your boss that you’re willing to take on the responsibilities
associated with the open position? Let your boss save money in the
budget! I have and it's been awesome - I've taken on teams that were
outside my prime area of expertise and it has forced me to learn. What's
better than that? You win, your boss wins!
3) Learning is a never ending process.
Especially in the technology industry. And, change is only
accelerating. It wasn't long ago that you could use a language for years
and not feel the pressure to learn a different language, now there are
new scripting tools appearing daily. Businesses are shifting development
paradigms! You need to think about the user experience across mobile
(phones and tablets) as well as traditional laptops and desktops. You
don't need to run hardware anymore, you can develop, test and have your
production environment in the cloud. Companies are now introducing
wearable technology - how do you think that will impact your business?
4) Communication, communication, communication!
For those of us in the technology field, there is a certain personality
that people associate us with - they believe we lack social skills and
don't understand how to interact with others. I am lucky that my parents
taught me how to communicate in groups at a young age. The fact that I
can move between non-technical and technical users and communicate and
share information has been a key driver in my career. The time has
passed where you could hide at your desk and not have to interact with
anyone. In the business environment that exists today, you need strong
written and verbal communication skills. You also need to be adept and
moving between technical and non-technical discussions and being able to
translate information between teams.
5) If you're not happy, find something else to do!
When you're dreading going into work every day, maybe you need to
change things up. Once job from my past, made me extremely miserable. I
didn't realize it in the moment, but after leaving the company and
taking on another role, I was able to look back at the experience and
understand how it had impacted me - and not for the better. It was a
miserable experience for myself and others. I wasn't the only one who
ended up leaving either. Over a period of time, a lot of good people
ended up taking on different roles in other organizations. What a loss
for that organization.
As I've grown into different roles and
moved between organizations, these realities have allowed me to tackle
new challenges. Each of us have our own core strengths. Figure out how
to maximize the impact your strengths have within the role you currently play.
If you'd like more information on my background: LinkedIn Profile
I credit the fact that I'm in this industry to Microsoft and IBM. I was enthralled with the introduction of a small business class computer that you could place on any desk and with the OS and applications that made computers accessible. Applications like Lotus 1-2-3, VisiCalc, Wordstar and dBase III. Yes, this was long before the introduction of graphical OS - they all ran on MS-DOS, don't cringe, a text based OS. And, yes, that means I was playing with these systems shortly after IBM introduced the first IBM PC - the year was 1983 and the IBM PC was only 2 years old.
While attending college, I got a job installing PC's, setting them up and introducing the client to their new system. I also picked up computers that weren't working properly and brought them back to the service desk to be repaired. At the time, PASCAL was the language of choice. I was learning how to program in this language in school and the company I was working for allowed me to take a Compaq Portable PC back to my dorm room. I convinced my instructors to let me use the Compaq for my programming assignments (I think I was using a copy of Borland Pascal - but my memory is a little hazy) versus having to logon to the DEC PDP 11/70 - a mini computer. I also was able to get my hands on copies of Microsoft Assembler and Microsoft Basic. Much as I hate to admit it - that was geek heaven at the time.
I loved the PC and MS-DOS. Config.sys and AutoExec.Bat were my friends - I knew how to get into these files and make changes to the way that the system operated and the utilities that would be loaded into memory. Microsoft and IBM made it fun and easy to use these new computers and made programming accessible. Ask my folks how many hours I spent in front of those early computers teaching myself without realizing how important this would be for the career path that later followed.
I ended up working for a couple of computer resellers early in my career - doing everything from installs, service calls, sales and teaching. Yes, I actually ended up teaching computer classes on dBase III and Lotus 1-2-3. Teaching dBase III actually ended up being the precursor that allowed me to get into programming. I started playing with Clipper - a compiler for the dBase III language. Then I applied for and got a professional programming job using Clipper. From there, as they say, the rest is history - moving through my career as a developer, consultant and manager.
None of this would have been possible without IBM and Microsoft partnering together and creating the business class personal computer. Ask anyone I knew back in those days and you'll hear about how I looked up to these two companies - in my mind, they were at the top of the top, no other company came close to the respect that I held for these two companies. And my early career was built on this market - migrating to Visual Basic and Visual C++ when Windows took hold.
IBM lost their way and fell down against the IBM compatibles - eventually selling their PC business to Lenovo. They couldn't figure out a way to compete on cost with the competition. Go figure, literally, the pinnacle of multinational companies could not figure out how to leverage resources across the world to compete against much smaller companies. (If you're looking for the full story on IBM's fall - and not just related to PC's - I'll send you to I, Cringely for further reading - The Decline and Fall of IBM.) IBM is gone from the PC industry and is seeing a decline across their other product lines. As much as I hate to see this company in the condition it is in, I tend to agree with the assessment that IBM is on it's way down.
Microsoft on the other hand successfully out maneuvered the industry - yes, Apple was there, but they were a niche player. Along the way, Microsoft made blunders - but was always able to recover. And why not - they really didn't have any competition, to the point where they were charged and found to be a monopoly. Using their weight to drive competitors out of the market. Ever hear of the phrase embrace, extend and extinguish? If you haven't - look it up, it will give you an excellent run down of the way Microsoft controlled the industry.
The first chink in the wall of Microsoft was the open source movement. Linux in particular and the open source programming languages and tools. More and more developers became disillusioned with the walled garden of Microsoft and began looking for alternatives - myself included. Linux, check! Apache, check! MySQL, check, Python, check! All open source, no cost barrier to development or deployment! What started out as an irritation became a full panic at Microsoft as they ranted about open source being a cancer in the industry. Today, Linux runs the web.
Then along came the iPhone. Microsoft initially made jokes about the iPhone - well, that humor came back to bite them in the back end. The iPhone and iPad have ended the PCs dominance. I know more and more people that are foregoing the purchase of laptops and desktops at home to purchase 1 or more iPads. And I'll also wager that Chrome is becoming a bigger and bigger headache for Microsoft.
Apple ruled the smartphone market for several years until Android came along. The one thing you won't hear is Windows Phone. Ok, I'll give Microsoft credit Windows Phone isn't bad, but I still prefer iOS. I'll use Android if I must, but I can never see myself going for Windows phone.
This is where I think Microsoft has really gone nuts - they created Windows 8 to run across phones, tablets and traditional PCs (laptops and desktops). For those of you that like Win8 - that is your choice. All I can do is speak for myself and I can not stand this Frankenstein of an OS. Mindlessly switching me between Metro and traditional windows mode when I want to do various tasks. I won't go into all of the details, there are plenty of articles out there that get into the details.
Microsoft used to be there for the developer - building the tools and making it easy to get stuff done. I can't say that anymore. Developers have moved on to iOS and Android - if it's convenient they'll build a Windows version, but it's usually well after they've developed for the other mobile platforms. Don't get me wrong, both iOS and the Android environments have their issues, but developers want to be there, not with Microsoft. And the consumers have spoken as well - at the end of 2013, Windows Phone had a whopping 3% of the world-wide market share of smart phones.
Today's kids want an Android phone or the iPhone - and, yes, that includes my kids. Do you think when they're ready to move up, that they're going to go with Win8 or with an iPad or a Mac? Some of them will move to Android tablets. Fewer and fewer of them are going to choose Win8 machines.
I don't know what Microsoft can do to change the equation. Is it too late? Well, the good news is Microsoft has a lot of money in the bank, they've realized that Balmer was leading them off a cliff and have replaced him, and they still have a following. Will something change in the equation - who knows, but if I was a betting man, I'd say Microsoft will never have the power or control that they had in the 90's and early 2000's.
Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;
For more information on David L. Collison: LinkedIn Profile
