Teamwork is necessary at multiple levels.

Collaboration is a virtue; practice it often.

Inside your team, you need to be collaborating with your fellows. From code reviews to answering questions to teaching/learning techniques, the people who work with others will always be more valuable than the lone wolf who buries himself in a corner.

Everyone needs teamwork across other development teams. For example, you have to coordinate releases across projects, develop coding standards, and share libraries.

This also applies throughout the technology department. You must have a strong relationship with your business analysts, quality assurance engineers, database gurus, network engineers, systems administrators, and operations.

Across the organization as well, you will find that strong relationships will help you immensely. You need to work well with marketing, sales, human resources, finance, and other departments outside of technology.

In some cases, teamwork is needed outside the company, starting with good vendor relationships, strategic partnerships, clients, and alliances. Even trade organizations and user groups come into play.

Teamwork is crucial at all levels and, thus, is a skill that you must develop to succeed in this world.

Application architecture should be simple.

This is one of those times where less is more.

They don’t hand out awards for making things the most complicated. Similarly, an application’s system architecture should be simple. Most of the time, no one would think that developers could improve an application by making it more complicated. So the design should be clear and obvious. It should also be easy to understand.

Many applications suffer from an overly complex architecture. These systems resemble a Rube Goldberg machine, with dozens of small components connected in a variety of fascinating interactions. Each small piece introduces another point of failure. Unfortunately, these components also increase implementation risks; the whole long chain fails if developers implement any of them incorrectly.

Thus, the architect’s goal is to reduce complexity by focusing more on what can be removed as opposed to what should be added. Therefore, when engineers look at the plan, they should feel like it is the most obvious and straightforward way to achieve the team’s objectives.

As work progresses on the application design, one of the goals should be to make future changes easier. Complex systems are very resistant to change because there are so many interlocking parts. On the other hand, a simpler plan will allow for easier enhancements later.

Unreasonable estimates destroy morale.

Software developers aren’t motivated by impossible goals.

Developers want to work on technically interesting projects. They enjoy the mental challenge. They also want to collaborate with like-minded, knowledgeable engineers. Most of them are highly analytical and work in a world of simple logic. Keeping developers motivated isn’t all that complicated; they just want to be treated fairly. When they go through the effort of providing estimates, it’s an honest, time-consuming exercise involving the analysis of every requested feature.

If upper management ignores that estimate and demands the work happen faster, it puts the engineers in an impossible position. The estimate was, after all, not a commitment; there are too many unknowns in software development to predict schedules with perfect accuracy. And typically, due to changes in requirements or external difficulties, development usually takes longer than the initial estimate. So demanding that all of this happen in a much shorter amount of time makes it an impossible goal.

If the development team’s estimates do not agree with the work schedule dictated to them, the project will be in trouble. The team’s morale will be low as they adopt an adversarial relationship with management. And, of course, management will be blaming the developers for not achieving the impossible goals. This is highly dysfunctional as the role of management is to support the team, not drive them into no-win scenarios.

Similarly, developers aren’t impressed by motivational speeches. I’ve seen sales organizations where the CEO gives an inspiring speech, with the sales and marketing teams cheering him on. Plus, there are trophies handed out with awards for the best sales leaders. In some companies, the crowd takes on cult-like behavior. In such organizations, setting impossible goals might be viewed as a motivational attempt to get the team to accomplish the impossible. But for developers, this behavior is viewed as dishonest and overly stressful.

Ultimately, unreasonable schedules lead to delays in delivery. It also leads to reductions in functionality and lower quality, all of which must be addressed later in the year – impacting all future schedules. It’s a short-sighted, ignorant approach that veteran developers have seen at other, lower-performing companies. Remember, they left those places for a reason.

Code that changes together should reside close together.

Finding code shouldn’t require a search party.

When working with a large codebase, it’s always frustrating when you need to search for code and don’t know where to look. Sure, you can easily find instances of specific names with any modern code editor. But sometimes, it’s harder to find code that’s merely related.

It’s natural and appropriate for logic to live in different classes. The Single Responsibility Principle will drive you to this, breaking up legacy classes and moving logic to other files. There’s nothing wrong with that.

The problem comes when you have various bits of logic that, while covering different responsibilities, are likely to change simultaneously.

For example, suppose you have a lending application and are implementing a new rule about interest rate limits. When working with administrative functions that enter interest rates, the limits will come into play. They may also require you to add information about a user’s region that you didn’t track before if the enforcement of the rule is regional. (Maybe a town in Kansas has a law that says no rates can be evenly divisible by 5.) The point is that you’ll need to make multiple changes to your codebase to make this happen.

Wouldn’t it be easier if all of the related code was nearby?

Try to locate code that relates to these concerns close together. For example, class files can be in the same directory. And then, within a class, methods that relate to each other should be located near each other. Don’t make future developers go hunting. Instead, make life easier for them and yourself.

Is the Recession Here?

Four weeks ago, I was thinking about the negative GDP report for the first quarter. At the time, I thought to myself that having Q2 also report negative GDP growth seemed likely. This would mean that we are in a recession. (Typically a recession is marked by at least two consecutive quarters of negative GDP growth.)

The last recession was caused by the lockdowns at the start of the pandemic. It was very short-lived because the economic activity went so far negative that it took every little to improve.

Lately, on CNBC, I’ve seen a lot of the talking heads bemoaning the chance that the economy could enter a recession later this year or in 2023. They feel the stock market has been in the dumps for the past few months because of recession fears.

I feel, though, that the recession is already here. That the recession has been here for a while. People like to point to the “strength” of the economy as a rebuttal to this idea. Yet, I’ve seen many tech companies cut back on their open positions. And a few have even started to have layoffs. The economy is not as strong as it used to be.

Meanwhile, inflation is running very hot. It’s been over 8% the past two months. The cost of gas is double what it used to be just a couple of years ago. Grocery bills are much higher than they used to be. A lot of the basic expenses of life are more expensive than they used to be. Most people I know are starting to cut back on some expenses as a result. People change their behavior when things cost a lot more suddenly. This has to result in negative GDP growth; thus, we have to be in a recession.

But it’s not all bad, though. The stock market predicts the future; it is not reflective of current conditions. So once more people admit we’re in a recession, we’ll soon start hearing forecasts of when the recession will end. The stock market will start to move upward in expectation of the next growth cycle.

So in my mind, this is a great time to be investing in stocks. And in crypto. Just make sure you’re investing in companies that have good, growing businesses. Not every company will recover nicely.

My Goals for 2022

It’s that time of year. It’s time to look back on 2021 and consider how I did against my goals. And, of course, time to set new goals for the new year. 

Life never returned to normal in 2021. In some ways, it was just a continuation of 2020, the year of the pandemic. I spent the year working from home, which has become the new normal. I traveled to New York City twice, but it was for work. It’s not something I’m excited about doing again. The city was full of fearful zombies that wore masks outdoors and took them off in bars and restaurants.

Working from home has many advantages, though. For example, I only had to fuel up my car four times last year, as I no longer use my car for commuting. Thus, I’ve been thinking of selling it. I’ve also been very healthy throughout the year. The vaccine keeps the effects of covid away, and avoiding people, in general, keeps the colds away. So that’s been nice.

The stock market had a great year. Even bitcoin had a good year, rallying to new all-time highs before falling back to $47,000. But that’s still a huge increase over the $29,000 it was at the start of the year. So I really have to wonder if the gains can continue yet another year in 2022.

Last year I set 10 personal goals. Here’s how I did on each of them.

✅ Write 4 longer short stories. I achieved this by mid-year and tried to finish a fifth one. Strangely, I still haven’t finished the fifth one, and now I’m facing the choice of wrapping it up or extending it into a novel.

❌ Complete six short online courses and two longer online courses. Early in the year, this was going well, and I finished five short courses. As I got involved in other priorities at work and home, I spent less time on self-education. This was unfortunate, as I truly wanted to learn more about blockchain and crypto technologies. 

❌ Make new friends. I didn’t have a plan for this. Thus, it’s not surprising I didn’t make new friends. Staying home all the time, I’m not meeting anyone outside. And the relationships I’ve made with people online I would not elevate to the level of “friend.”

✅ Catch up on periodicals. I almost didn’t make it. I finally caught up on December 30th. As this won’t be a goal in the future, and I’ll significantly reduce the number of periodicals I subscribe to, I should have time to work on other things.

✅ Read 25 books. This goal is another one I barely achieved, finishing the 25th book at the end of December.

✅ Maintain my exercise habit, a healthy diet, and lose more weight. I succeed at this. I didn’t lose much weight, but I did lose some. Also, I stayed healthy throughout the year. Thanks to the pandemic, I attribute much of me staying healthy to working from home and avoiding people.

✅ Gain 15% on my portfolio. It was another great year for investing. Both the stock market and cryptocurrencies did very well. So well, in fact, that I fear 2022 may be a down year.

❌ Sell, donate, or dispose of three shelves’ worth of old stuff. It was too easy to leave things on the shelves. As a result, I didn’t achieve my goal of reducing clutter.

❌ Take two vacation trips. Thanks to the never-ending pandemic, I never thought seriously about taking trips or cruises. Even with the vaccines and boosters, it just doesn’t seem appealing. I thought I might take a road trip somewhere, but that didn’t happen either. Ultimately, I took vacation days here and there to relax at home.

✅ Achieve gainful employment. I landed an excellent job in February, and I’ve been there ever since. It was the ideal outcome. I work on an interesting, award-winning application. I also enjoy my coworkers; they’re great. And finally, I’m getting the experience of managing a globally distributed remote team.

So those were my 10 personal goals for 2021. I succeeded on 60% of them, typical of the past few years. Maybe one was partially successful, but that would only make it 65%. I want to do better. This exercise is about more than just hitting the goals, though. It’s about having goals, and watching them throughout the year. If you don’t set objectives, you’re not going to get there.

For 2022, I have a new set of goals.

Complete three home improvement projects. I have some specific projects in mind. I’ve been putting them off, so I aim to get them done this year.

Get back to taking vacations. It’s been two years without one, so, one way or another, I need to find a way to resume taking vacations.

Close unused accounts. Over time I’ve accumulated credit cards and things I don’t use anymore. I want to get rid of these things.

Simplify life. There are some things I can do without. For example, I can sell the car I rarely use anymore and get rid of some of the clutter around the house. It also includes automating more bill payments, saving some tedious work.

Improve bookkeeping. With the various crypto transactions I have and other investments, I need to improve my records.

Reduce expenses. I have some specific items in mind here to reduce some of my monthly expenditures.

Gain 15% on my portfolio. This one is very straightforward, although it may be a challenge. After several great years, the stock market may not perform as well this year. In addition, rising interest rates may impact stock valuations. However, inflation may benefit some investments.

Consolidate accounts. I should transfer and consolidate some accounts that have little activity.

Medical goals. This includes various vaccination goals. It also means achieving a weight target through a combination of watching my diet and continuing to exercise. 

Continue education. I have a series of courses I intend to take. I also want to practice some technical skills through a set of small projects. Finally, I plan on creating a crypto project and some NFTs.

Make new friends. My plan this year is to leverage half a dozen systems to create an equal number of strategies to make new friends. The goal is to make three new friends by the end of the year.

Improve writing skills and make stories. This goal has several components, the first of which is reading 25 books. I also want to edit several of the short stories I’ve written in the past year and get one published. Another goal is to write a short nonfiction book and outline a novel. Actually, there are several sub-goals under this goal, and it will be challenging to do them all.

All told, that’s 12 major goals for the year, most of them with several sub-goals. However, I’ve already made some progress on them, so the year is starting well. Again, these are my personal goals; I have not included my work-related goals here.

Don’t run with scissors.

Exercise extreme caution when removing data.

One must be very careful when deleting data. It’s far too easy to delete the wrong data by mistake. This kind of error can lead to extensive system downtimes and upset clients.

Before removing any data, query the data set to be deleted and examine it closely. Sometimes this simple action can reveal data elements that you should not remove. For more massive data sets, sample the data multiple times. Also, one can summarize the data to be deleted and look at counts and totals.

Also, make sure you have backups. It can be extremely unfortunate to delete the wrong data accidentally and then learn, too late, that your backups are not functioning correctly.

Even highly experienced people make mistakes. Don’t get cocky!

Some bugs are caused by bad assumptions.

These assumptions can cause widespread problems.

When you fix a bug that was based on a bad assumption, look for other areas of the code where those bad assumptions where used. Chances are good that there are additional bugs caused by the assumptions, bugs you haven’t found yet.

You may find many other bugs that have gone unnoticed as a result.

Always question your assumptions. It’s very easy to get the assumptions wrong, as they are often communicated to you through several people, each of which may accidentally alter it slightly.

Make you sure you document your assumptions in a shared knowledge base. An internal wiki like Confluence or other similar products is good for this.

Find the first error.

A large series of errors is usually triggered by a single error.

When problems occur and you have a long stream of errors, try to find the first error. Most of the time, everything after that is a side effect. Like a chain of dominoes, the first error causes all the others to occur.

Sometimes that first error is hidden, or lost in other noise in the log. It’s not always obvious, but definitely dig for it.

Try to solve the root cause instead of treating the side effects.

Write a test for every fault you find.

It’s a simple way to avoid repeating mistakes.

You get this for free if you follow the highly recommended practice of test-driven development.

If your code base doesn’t have that kind of coverage, always be sure that there is a test to cover fault, bug, mistake, error and unexpected result that you encounter.

There’s nothing worse than having bugs come back later. When you repeat the same mistake twice, did you learn nothing the first time? Avoid this.