Photo by Sharon McCutcheon on Unsplash

Many organizations with large or complex application portfolios struggle with prioritizing development on existing solutions. It seems difficult to justify effort and resources particularly if the system is actively serving its purpose. The expectation to keep these systems operational without a long-term plan becomes difficult to manage and outright demoralizing. Years of modifications, workarounds, and unused code begins to take a toll. Communicating the reality of these challenges is often misinterpreted or ignored due to the inherent complexity.

The Problem:

The root cause of the conflict is buried in how business have traditionally approached…

Photo by heylagostechie on Unsplash

Let me start with this — I’m not a huge fan of code reviews as a tool to “check someone’s work”. It’s pretty condescending to walk in at the last minute to offer criticisms. If someone needs help working through a problem, then paired programming is a much better option. With that said — pairing isn’t always possible so there are cases where it needs to be done. There are also times when a developer wants a second (or third) pair of eyes. …

Photo by Christina @ Unsplash

Congratulations, you have proven yourself capable and have been given the responsibility of providing technical oversight for a group of developers. So what do you need to do to make sure you fulfill expectations?

To begin, “tech lead” can have different meanings depending on the company you work for. Start by having a discussion with your boss so that you fully understand expectations.

Next understand that in this role you are responsible for the technical side of the implementation. This includes decision making, quality, translation, and communication.

As a technical lead, here are some tactics you can utilize to ensure that you will deliver on expectations.

1. Create a collaborative but guided processes to make…

We all do it. I’ve looked back at something that took me weeks to build and said to myself, “Wow that could have been far more simple.”

I blame it on brain “modes”. When we put our brain into solutioning mode — we forget the problem and begin constructing a solution we can take pride in. I suspect it has something to do with creativity. It’s not limited to software development either — I credit overengineering for that really complex change management process or that 200 page employee handbook you may have been asked to read.

In the end there…

Any organization that has been around for some time has “that” codebase that no one wants to talk about. It was written in a rush, features have been layered over time, the technology is stale, and any time you touch it — pain.

This can be an even larger issue if that pain is only experienced by the development team. If business units and stakeholders are able to ignore — it creates some very real contention.

The most common challenge with legacy technology is it’s existence seems to provide value but the justification for a major development investment hasn’t yet…

So I am on a plane with my family heading home from a summer vacation trip. As I am helping my youngest son get situated, showing him how to select a personalized in-flight movie, my naturally retrospective mind thought back to the days of when you were lucky if the flight you were on had a movie at all. It made me appreciate how convenient entertainment had become on flights. Understand that flying isn’t one of my favorite things to do — I am much happier when the wheels hit the ground. …

After years of blood sweat and tears I decided to call it quits. My optimism got the best of me and I honestly never envisioned things working out the way they did. I always thought success was inevitable. The truth is it was doomed from the beginning, but in the end the experience has taught me a valuable series of lessons.

I relied heavily on my partners experience and didn’t take the time to assess its relevancy.

My partner had years of experience in the business and tons of domain knowledge. I had around 10 years of experience building software and so it felt like it was a great match. …

Maybe it started out well — but over time it grew stale. Or it was wrong from the very beginning. Despite the common belief that software is an asset — it’s just as easily a liability.

Let’s start with how do you define “Meaningful” software? Developers know when something they are working on doesn’t matter. Sometimes the indicator is a lack of interest in investing further or it’s heavy investment in something that gets little usage. Either way meaningful software must be a win-win for both creator and consumer.

“Meaningful software delivers value to a substantial segment of the target…