DEV Community: mlr

The Thunder Island Navigator

mlr — Sun, 28 Jul 2024 01:10:38 +0000

Join Me On a Career Journey

I haven't posted in a while because I've been working on The Thunder Island Navigator, a newsletter about the software engineering field and job market to help aspiring (and seasoned) developers navigate the current market.

I've built the newsletter using Beehiiv, which has lots of canned no-code tools to build a simple web page for subscribers and potential subscribers. For registering and managing the domain, I used Namecheap, which was a really smooth experience overall.

As of right now, I'm aiming to post a new article every Monday, Wednesday, and Friday. I may have some special edition articles published on other days, depending on my work schedule.

Why?

My motivation for building the newsletter is twofold. First, it is meant to both to help others navigate the software engineering market and educate people on the field as a whole. Second, I hope to gain some exposure to my own projects and network with other developers to learn and grow.

How Can You Help?

I'm looking to do interviews with developers who want to talk about their job search, career journey, or the cool personal software projects they work on.

I'm also looking forward to hearing comments or stories from developers who are currently looking for jobs and want to voice the challenges and trends of the market they've encountered in their search so far.

If you want to reach out to chat, please feel free to send me a message here or by email. It would be great to hear from everyone.

It would be greatly appreciated if you could visit the site, add your email, and click Subscribe!

The direct link to the newsletter is here: https://www.thethunderislandnavigator.net

Code on,
Matt

Focus

mlr — Sat, 22 Jun 2024 19:24:11 +0000

One of the five Scrum values is Focus. There are many ways in which developers can apply the concept of focus. There are also many ways in which developers, managers, and organizations as a whole can impede the application of focus.

When developers lose focus, the quality of code suffers, productivity suffers, and most importantly, the developers suffer.

Singular Goal, Realistic Planning, and Elimination of Multitasking

In Scrum, there is always a Sprint Goal. This goal is singular, transparent, and as brief as possible, which helps developers focus on an achievable outcome.

Realistic planning makes a world of difference for the outcome of a Sprint. Developers have issues that come up during the Sprint, they get stuck on problems in the code they’re trying to write, unexpected business needs come up; I could go on and on about this one. Planning more lightly makes it easier to be flexible and still deliver on the goal.

Eliminate multitasking wherever it crops up. It’s often the case that management has dictated that progress must be demonstrated on a daily basis towards multiple different outcomes. In some cases, developers try to switch back and forth between two or three work items throughout the week without finishing any of them. There are all sorts of cases in between and outside these.

Examples

Let’s look at a couple of scenarios that might resonate with you.

Scenario 1

The developers work on enterprise applications in an IT department for a finance company. There are 20 different applications for which they are responsible. Every Sprint, a mix of critical items for the bookkeeping software, CRM, and mobile banking app are added for developers to work on. The plan has been "maximized" for the amount of work management thinks the development team can handle over the course of the Sprint.

Each developer has gained specialized knowledge of one of these applications and has taken “ownership” of the application. Alice specializes in the mobile banking app, and Chris specializes in the bookkeeping software. Both Alice and Chris also help the remaining developers work on the CRM. Management wants to see progress on each of the three applications every day for each developer.

By the end of the Sprint, nothing has been released. Small advances were made towards completing some of the work for each app, but it will take at least one or two more Sprints before a release can be made for each of the three apps.

Scenario 2

The developers work on enterprise applications for a global shipping company. They have several different applications they are responsible for, much like the team from Scenario 1. During their current Sprint, they have planned to work on a new feature for the inventory management application. The new feature will allow other employees of the organization to add images and details about faulty products in the inventory and report them to inventory management and operations teams for investigation. The feature is a small part of a much bigger tool they want to integrate into the application for managing and reporting faulty products. With that in mind, they have planned lightly, allowing for flexibility to add or remove items and still accomplish their goal.

Each developer on the team selects one item to work on at a time, all of which are related to the eventual release of this new feature. As developers get stuck, they ask others on the team for help and work together to remove blockers as soon as possible. They complete all their work for the feature halfway through the Sprint and are able to pick up additional work to fix some bugs in the application and pay down other technical debt.

Analysis

The team in Scenario 1 is likely familiar to most of us. I’ve worked at several places that take this approach. Management lets the team plan the work but says the team must work on more than one specific goal, they must maximize the amount of work planned, and they must demonstrate progress is being made on all the applications every day.

Having no singular goal encourages the team to break into specialist groups where some developers work on a specific application and everyone else gains little experience in the domain. Inevitably, when another developer gets stuck on their own work item, others on the team must pause their work—work that is in an entirely different application—and switch over to helping that developer. In this process, the developer(s) who have swooped in to help have to shift their mindset towards the new application and go through significant learning in order to familiarize themselves with the problem. By the time they switch back to their own work, they have lost track of what they were doing and have difficulty restarting.

Lastly, in this scenario, the original plan for the Sprint left no room for flexibility. If a team member gets stuck and takes longer than anticipated to complete their work, then there’s little chance of a release happening any time during the Sprint.

On the other hand, the team in Scenario 2 created a clear goal for their Sprint around creating a small, usable feature that was part of a much larger tool. They planned light to accommodate any issues that might arise or unplanned surprises. Their common goal and light planning meant that they could essentially eliminate multitasking, focusing entirely on moving one item at a time towards the bigger release, only having to switch contexts when offering assistance to a peer. Even so, the close relation between all the work in the Sprint implied the lagged time between each context switch was minimized as developers were able to share knowledge across the same domain.

Conclusion

To reiterate, it’s critical for the success to allow developers to focus. Three great starting points to accomplish this are:

Have a Sprint Goal: The Sprint Goal should be singular, clear, and concise.
Realistic Planning: Have a light plan that can accommodate more or less work as issues and surprises arise.
Eliminate Multitasking: Arguably, points 1 and 2 feed into making this possible. However, developers and managers must understand that multitasking involves context switching, and the lag time accrued in context switching causes a loss in productivity.

Let me know which of these two scenarios is most familiar to you or if you've encountered another type of workplace or management style that doesn't match up with either of the ones here. Thanks for reading!

Little Bugs, Big Problems

mlr — Tue, 18 Jun 2024 01:32:37 +0000

Software Engineering Manager: “Why haven’t you finished this bug? It’s been in implementation for three days… it’s just a bug, it shouldn’t be this hard.”
Developer: “...”

This interaction is common in software engineering. In this article, I’ll discuss how bugs are perceived by management, product owners, developers, and others involved in the development process. I’ll elaborate on perceptions of priority, work effort, and impact with examples from my experience.

Three common themes with bugs in past organizations:

UI Bugs are Top Priority: Management and product owners often see non-UI bugs as less important.
Bugs are Easy to Fix: Bugs are perceived as less complex than creating new features.
Developers are too Skilled to Write Bugs: Insufficient code reviews lead to bug-prone codebases.

Why These Perceptions Exist

UI Bugs are Top Priority

Some managers and product owners prioritize the visual interface as the most valuable part of the software, disregarding how functionality issues elsewhere affect the interface.

Bugs are Easy to Fix

Teams think bugs are easy to fix because the feature’s code is already written. However, it often requires more than a few tweaks.

Developers are too Skilled to Write Bugs

Without an engineering framework, the development process becomes disorganized. Lack of code reviews leads to isolated and complex bugs, weakening software architecture.

“Just don’t write bugs…”

— Every software engineering manager ever.

I’m not advocating for the above quote. We all write bugs. The key is changing how teams perceive the work needed to fix bugs, reducing complexity, and improving interactions about bugs among team members.

Examples

Organization 1: Mobile Developer for Hire

I worked on a small team building mobile apps with high turnover due to a lack of structure. Developers were frustrated by endlessly fixing broken code without checks and balances. The codebase was a giant ball of mud—functions were tightly coupled, state was unmanaged, and a single class managed everything.

I was tasked with fixing a UI bug, while 100+ non-UI bugs affecting measurement accuracy were ignored. After two weeks without progress, I proposed organizing around trunk-based development, implementing code reviews, and refactoring the architecture. This plan took months, but we eventually fixed the controls bug and many others.

Organization 2: Enterprise Data Analysis Software

Enterprise software always seems riddled with bugs. At one organization, a bug titled “Issue with Customer Interactions Populating” required refactoring the state management system. Management thought bugs were easy to fix because the code was already written. It took days to identify the problem and refactor the system, fixing several other data issues along the way.

Despite showing my progress, the manager was frustrated by the time taken. In the end, the codebase improved, but I didn’t receive recognition.

Organization 3: Big Finance

Financial software requires 24/7 uptime. This team believed experienced developers didn’t write bugs, leading to a lack of code reviews and collaboration. Critical bugs caused production rollbacks and hotfixes, wasting time and causing blame.

We proposed requiring two code reviewers per PR to ensure quality. This change boosted code quality and caught bugs early. Pair programming and mentorship improved team health and software quality.

Conclusion

Misconceptions about bugs being easy to fix, less important than UI issues, and the idea that skilled developers don’t write bugs lead to challenges. Recognizing the true complexity of bugs, prioritizing structured code reviews, and fostering better communication can enhance code quality, reduce frustrations, and deliver reliable software solutions.

Please let me know if you want to hear more about my thoughts on development, the software engineering industry, or related topics. Thanks for reading!