Today is a big day for me. It doesn’t feel like it though. It feels just like another day to be honest. Other than this will be my last day working in my current place of employment of 8 years, it really feels like any other day. My level of duties and responsibilities has diminished greatly in the last 30 days after tendering my resignation thus relegating me to daily knowledge transfers and answering questions both technical and philosophical. But it feels like it’s just another day in the office. It shouldn’t though.

I have spent almost a decade with the same employer across two countries. That is a big deal for me given that every other job role I’ve ever had before this only lasted 12 to 18 months. I was a serial quitter and I was damn proud of it. I was a technical consultant early on in my career. Which meant I pretended to know more than I really did to get hired and then scramble to learn really quickly on the job without anyone noticing (at least not my hiring manager). This environment trained me to have the original NASA mantra of “Failure is not an option” (which was later reneged for very good reasons). I was young and indestructible. I capitalized on my fluid thinking or more commonly known as grit, stubbornness, bravado or just plain; too dumb to know better. There is power in inexperience. Not knowing any better makes you try things no one else would. Lessons are best learned by making mistakes on your own. You never really appreciate the value of a design pattern until you’ve done things the wrong way first (sometimes even a couple of times first)

I was a serial quitter and I was damn proud of it.

Mad Computer Scientist

My serial quitting was just a symptom of what was really happening to me. I was trying to chase the technology. I was more interested at getting better at technology than I was at improving the lives of my customers. I was solving problems with technology for technology’s sake. I have to be honest, I still get tempted a lot to do it to this day but my better judgement and crystalized knowledge (fancy term for experience) has made me a better advocate of user’s needs over developer wants.

I was more interested at getting better at technology than I was at improving the lives of my customers.

Mad Computer Scientist

This has also greatly influenced my way of dealing with junior developers on my team. I always entertain discussing stupid ideas (fine, unorthodox ideas) and at times even letting them try it. 9 out of 10 times it will not work or have issues with it. But they will have learned something from it. Some may say that a 10% chance of it working is a bad bet but remember there is a 100% chance to learn here. This is where the revised NASA mantra of “Failure is ALWAYS an option” holds a lot of value.

The employer I am leaving today has given me a lot of opportunity to pursue a number of roles without having to leave the firm. For that I am grateful. I make it sound like it was all done with career planning but to be honest it felt more like I was bumbling from one job role to another and was just making the best of where I landed. And maybe that isn’t such a bad thing. During my consulting and startup years I never feared the jump. It was always a welcome change both for the customer (who most often than not was satisfied with what I had delivered and was no longer willing to pay me more money) and myself (so I can move on to the next technical conquest). I had never planned ahead which customer to work for next or what new technology stack I would need to learn to get them. It was the same bumbling around and making the best of where I landed strategy.

I was bumbling from one job role to another and was just making the best of where I landed. And maybe that isn’t such a bad thing.

Mad Computer Scientist

I had always been lucky to have had some of the best managers someone like me could ask for. I would always make the pledge to them that it was my job to do everything I can to make them look good and in return all I ask is that they give me everything I ask for (because what I ask for will be used to fulfill my pledge to them). This kind of deal ensures that I am empowered to do what I can to succeed while keeping my desire to over engineer in check. The worst kind of manager is someone who tells you exactly what to do and the worst kind of employee is the one that you need to tell exactly what to do. You need to give all your employees autonomy so that they can achieve mastery at what they do as they find their purpose along the way.

Human beings have an innate inner drive to be autonomous, self-determined, and connected to one another. And when that drive is liberated, people achieve more and live richer lives.

Daniel Pink

Frameworks and Platforms

I spent the early part of my career here as a developer for a UI framework that eventually turned into a platform. I have always known that software frameworks are critical to developing large scale software. They provide development teams a reusable set of features that they can pick from when building out their business applications. More importantly though is that it gently nudges them in the direction of building it the right way. Frameworks not only give you features, it also shows you how other teams have built certain things based on how they have used your framework. These ways of building things eventually becomes your standard pattern and practices. This is not only extremely powerful in building re-usability but also in cultivating a culture of how things should be done.

My biggest regret with this part of my career was not being draconian enough in enforcing these good patterns and practices to the development teams that used my framework. I had gone as far as training them, providing consulting, reviewing their code and even writing some of it for them. But because of the framework’s ability to allow development teams to write non-MVVM code (it was actually a feature of the framework to allow VB6/ASP.NET developers to easily adapt to it by letting them write code behind logic) it meant that the culture of following the pattern of isolating UI logic from the UI view was not getting adopted. I could have trained (or even berated) developers more but just like water they will take the path of least resistance.

Products and Services

I eventually stumbled my way into owning products. In this phase I had to choose existing frameworks internal and external to the firm. I made some bad choices when I decided to use a free open source product that we had to hack heavily to fit our needs. The cost of the development and maintenance only started to show up after a few iterations. Which is when I decided to make my second mistake of choosing a really expensive external product to remove all the custom development work. The product did launch and is still in use to this day and users love it, sort of, warts and all. This experience reminds me of Fred Brooks’ “Second System Effect”.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.

Fred Brooks

Fred Brooks obviously schooling me almost half a century in advance (first put to paper back in 1975 in his book “The Mythical Man-Month”). The painful part is that I am very aware of this tendency decades in advance but was still unable to avoid it. In my defense, the first chapter of the book “The Tar Pit” does discuss how building large software systems like a product actually requires a lot of effort. And I was able to successfully build, maintain and promote a number of internal products across the firm in my tenure here. There, I feel better now.

Another great lesson I learned while working with products and services is that your job is not done once the code is running in production. It actually has just begun. The only way a product will be successful is if you have the customer’s best interests in mind. This is most critical during the initial phase of adoption. Every single complaint, no matter how insignificant has to be addressed whether it’s a bug that needs to be fixed or a business concern that needs to be discussed. The product’s level of success is dependent on the customer’s ability to use it effectively. A product with a 100 great features will not be successful if the 5 features that customers really need are not built well. There has to be a relentless effort to improve the product early in its life cycle to promote wide spread adoption of it. You literally have to bend over backwards to make your most committed customers (usually the first ones too) love it. They are crucial to your product’s adoption and success.

Finally and probably the most underrated lesson for product success is that of support. Once users are hooked into using your product (even if they we’re using it in anger), you need to be able to provide a stellar level of support. It is not enough to let your users know that you are listening to their complaints, you should also be doing something about it. I have learned that a product’s good reputation is based on how well the support’s reputation is. In selling your product and further widening adoption, I’ve learned that reputation is more valuable than an impressive power point sales deck.

Developer Experiences and Reference Architectures

I also had the opportunity to work on initiatives that was a lot more far reaching. Projects that dealt with standards and tools that affected large parts of the organization. These we’re projects where I can start to do real damage 🤣. This was also the most productive time of my tenure at the firm. I had built up enough reputation and a sizable network of colleagues that the right people has started to listen to me. Although most people still saw me as the crazy person pushing forward an impossible agenda of a better way to do software development in a very inefficient industry.

I once spoke to a C level person who had an inclination for technology. He was hired to try and change the culture of the firm to make development teams adopt an open source mentality. I had doubts about the odds of this successfully trickling down from the group level down to the developers. I believe that there is no way of changing the culture at a massive scale without having a mass extinction first. This is the reason why a lot of firms fail horribly at adopting agile, devops and internal open sourcing. These are things that show up as a side effect of efficient development teams that actually want to help each other. In a large organization like ours, people and responsibilities fall through the cracks. If your developers do not already possess a mindset of helping other developers become better, then the system will work against them in so many ways. A manager holding a developer responsible for something is worlds apart from a developer holding him or herself responsible for something. That is the level of culture change that is required for teams to become agile, have a devops mindset and for internal open source to become successful.

You can never buy yourself into becoming agile, having a devops mindset or doing internal open source. All these require that a culture of helpfulness already be ingrained into the developers.

Mad Computer Scientist

I had the opportunity to contribute to a shared technology group during my last few months at the firm. We had a very clear vision of what a shared technology group should be. Build an internal technology consulting group that was comprised of experienced technologists from different parts of the firm. All bringing their specialized skills and varied experiences from different groups amalgamating into one super team. Well, at least that was what I thought in my head. Turns out having a team of technologists that is supposed to help solve problems at the enterprise scale is a very tall order. Commitment was the biggest one in my opinion. Putting together a team of highly skilled individuals means that those individuals had to leave their current roles. Which more often than not in this climate of “lots of work, not enough people to do it”, means they will have to pull twice their weight. Very similar to an open source library, the cost is hidden. The library is free to use but very expensive to maintain and extend. Creating a group of technologists that become the consultants of the universe will only work if the team is not carrying baggage from other projects. They can only be an internal consulting group if they actually act like consultants.

A shared technology group that is comprised of shared developers is a hobbyist group.

Mad Computer Scientist

There is a group though that I will be trying to emulate in my next role. More commonly known as the DXRA group which stands for Developer Experience and Reference Architecture. The group name actually describes what the team does. They build common framework libraries, provide patterns and practices and proven architectures for reference. Development teams are then expected to re-use or extend these libraries by following the clearly defined interfaces. This is where the balance needs to be struck. Become too autocratic and your framework becomes difficult to extend. Be too loose and development teams will run amok with their own ideas of how to best implement things.

I really like the focus though on the developer’s experience. I think this would be the best metric to gauge if you have the balance right. Focusing on the developer’s needs leads you to technology choices that helps them build business applications without having to think about non-business functionality. Authentication and authorization are great examples. A good developer focused strategy would be to provide a default provider that covers most of the developer’s needs. But at the same time expose a sensible interface that allows developers to change out the default provider implementation so they can easily change out to a different implementation if necessary.

Credits

To my managers (the pencil pushers). I have been very lucky to have you. I would never have been successful without all of you. I have learned a lot from you guys on how to become a better leader and overall a better person. Thank you so much.

To the engineers (the button pushers). Never stop pushing buttons. Remember “Management is the path to the dark side. Management leads to anger. Anger leads to hate. Hate leads to suffering”. We, the engineers run this place. Literally. Any industry will not run without engineering. We should realize how valuable our role is and have pride in the work that we do. We should all elevate our standards and make sure we improve the world one line of code at a time. Let us all avoid the perils of saying “I don’t have time to make the code better”. There is absolutely nothing else more important for us other than making the code better. We are lean, mean, software engineering machines!

To the firm. I shall forever be grateful for the opportunity of serving 8 years. Wait a minute, why am I talking to you? You’re not even a real person! But thanks anyway. 🤣

Management is the path to the dark side. Management leads to anger. Anger leads to hate. Hate leads to suffering.

Mad Computer Scientist and Yoda

Notes For Future Me

• Create frameworks that force (fine, challenge) developers to be better
• Open source is not achieved by forcing everyone to help out. It is a side effect of people helping each other out
• You cannot buy yourself into devops by just buying software, infrastructure and people. You need to change the development culture to make developers want to do test automation and continuous deployments
• A product’s reputation is not based on the amount of features it has but by the amount of support users can get for it
• A shared technology group that is comprised of shared developers is a hobbyist group