My name is Neil Green. I am a software developer who currently lives and works in the United States. I am originally from The Bahamas and I came to the US with nothing but a single duffel bag to attend university for physics. Over the years in college, my interest shifted away from high-energy particle physics and towards this new thing called “the internet.” I left university to take my first job at a startup in Atlanta, which not coincidentally was where my girlfriend (now wife) was going to pursue her PhD. My wife (Dr. Wife now) and I met in calculus class and we have been together for as long as I’ve been writing software, which now is over half my life.
I have spent the last 20+ years engaged in every aspect of developing software imaginable. I have been a junior developer, a principal engineer, a technical team lead, and an architect. I have been promoted, laid off, fired and resigned from more companies than I care to mention. I have been self-employed, worked for small start-ups, as well as for large publicly traded companies. I have seen projects from conception to production, and have witnessed projects crash and burn first hand – sometimes due to my inexperience. I have learned more from my failures than I have from my successes, and I learned my most important lessons the hard way – sometimes the hardest way possible.
And yet, I have emerged a more skillful developer, a stronger team player, a more effective communicator, and a wiser (and hopefully better) human because of it all. During my career, I have had several mentors that helped me grow my technical skills from that of a novice to that of an architect, but there were not always people willing to- or able to- give me constructive career advice, communication coaching, or guide me as I attempted to find my place in what were often cut-throat corporate environments. As a result, I created Neil on Software to share a few of the tidbits of wisdom I wish someone would have shared with me along the way.
Unfortunately, I have met the criteria for several of the Difficult Developer archetypes from my work on “How to Deal with Difficult People on Software Projects” at various stages of my career:
- I have been The Extreme Underestimator several times, coming in 300%+ over time budget on more than one occasion.
- At various points in my career I’m sure my managers considered me The Diva, whether I deserved the label or not.
- Mid-career I was desperate to be placed in a managerial role, and while I was working to get promoted I was The Aspiring Manager.
- Once I realized that I preferred technical leadership over management I became The Wants-to-be-Technical Development Manager.
- After I had transitioned out of management, for about a year I was The Incompetent.
- I have always been The Idealist, which has caused me no end of troubles when I found myself in the wrong environment.
- I have been The Hostage Taker when I was trying to mature a framework prior to handing it off to other developers, and while it wasn’t my intention I was indispensable during those periods.
As you read through my content, you may wonder if you should take my advice or care what I have to say. I can’t answer that question for you, but here is what I believe to help you make your own decision:
- I believe in level playing fields, whereby everyone has an equal chance of success, but that success is not guaranteed.
- I believe the fairest environment is a meritocracy where people are judged on what they can do rather than their attributes.
- I am a realist firmly grounded in reality, which is a position that is neither pessimistic nor optimistic.
- I believe that every individual is different and should not be treated as a small, fungible cog in a big machine.
- I believe the best software teams are made up of individuals each having a unique strength, and whose weaknesses are balanced with the strengths of their teammates.
- I believe that problems should be defined before an attempt is made to solve them.
- I believe your choice of tool should be made after knowing the problem you have to solve.
- I believe in knowing all of your options before you make a decision, with the first option always being to do nothing.
- I believe that in the face of new information, we can and should change our minds.
- I believe that the majority of issues found on a software team can be dealt with if an emphasis is placed on respect and trust rather than process and procedure.
You can reach me at email@example.com.