Everybody "needs" to be capturing emails

It's a sentiment I hear a lot. Maybe due to the people I talk to and the podcasts I listen to.

I get why it can be important to capture emails for promotion but as I don't yet have anything to sell you (other than myself--BTW, I'm currently available for work) do I really need this? Maybe I should as it may come in useful one day.

I recently got locked out of the service I previously used to capture emails and that has made me rethink this topic.

It doesn't feel like it's in anyone's best interest for this site to have a pop-up asking for your email but I probably should have a simple way of letting people provide this if interested. SO, now there's a page linked in the header and no pop up. You're welcome.

While I've nothing to sell you today, hopefully I'll have another book finished later this year and my mailing list will be first to hear about that.

If you might be interested, click here or on the link above to join.

Variations on "the boy scout rule" in coding

Many developers talk about versions of the boy scout rule of:

"Try and leave this world a little better than you found it."

Not everyone interprets this the same way and I'm aware of 3 basic variations:

1. Make improvements as part of every change.
2. Leave it (the code) as you'd like to find it.
3. Leave the code a little better than you found it.

Some developers use variation one as an excuse to include their preferences or desires as part of other changes.

Some developers use variation two as an excuse to rewrite the pieces of code they're working on in the way they'd have written it originally.

Some developers think that variation three means that they have to make other changes to a codebase in addition to whatever new feature or bug fix they're working on.

I'm not sure it's any of these interpretations.

This "rule" or "principle" is generally good. Understanding how some people might be manipulating or mis-understanding it can be more helpful.

I like to understand the rule to mean:

"While I'm in this area of the code, are there any important things that also need working on? Or are there any simple fixes I can also address while I'm here?" 

I'll then make those changes as separate commits and/or PRs either immediately before or after whatever task caused me to look at that code.*

I've previously heard this as "code-gardening". It's like the day-to-day removing of "weeds" you notice while doing other things in the garden.

Hmm, there's probably a gender neutral version of this rule we should also consider using instead.

* Side note: I massively improved the work rate at one company when I suggested they switch from randomly assigning changes as part of each release to having all changes related to one area of the code be done by one person and at the same time. This was a very large and very old codebase with a medium-sized team working on it. The change in allocating work removed the majority of merge conflicts and issues from multiple people wanting to work on the same files at the same time. It allowed people to gain a deeper knowledge of some areas of the code, rather than everyone having a superficial knowledge of a lot of it. In turn this meant that solving trickier problems became easier as someone already knew the code well. The change in working allowed developers to take "ownership" of the code they were working on as they'd spent so much time on it and so cared about the quality. And it increased collaboration between developers when they were assigned a new area to work on with the next release. "You, worked on this area for the last release, what do I need to know before I take it over?" Overall, they started shipping faster and with fewer bugs being introduced.

I'm reminded of that change when I hear someone mention the BS rule.

Maintainable software requires these three things

For software to be considered maintainable, it requires 3 things:

1. For there to be (documented) knowledge of everything the software does (and doesn't/shouldn't) do.
2. For there to be a simple way of verifying the software behaves as intended.
3. For it to be written in a way that makes it clear to a person looking at the code what it does, so it avoids any unintentional side effects when changed.

Point 1 doesn't require a specific format or way of recording this information. Use what works best for you, the team, the company, and the project.

Point 2 can involve a combination of tools and may require some manual effort.

Point 3 is dependent upon the skills and existing knowledge of the person making a change. It's okay to require a minimum level of knowledge of the language, framework, codebase, etc. The goal, as far as possible and in combination with other requirements, is to have unambiguous code that is clear about what it does. (With documentation--and possibly comments--explaining why, where necessary.)

"As an architect, part of my job is to improve the way we do things"

I was recently listening to a podcast and was struck when the interviewee (a "senior software architect" at a large company) confidently stated that:

"As an architect, part of my job is to improve the way we do things."

Two things jumped out at me about this statement and the way it was made:

1. It implied that other people at the company don't look for ways to improve things.
2. It implied that other people at the company aren't allowed to suggest improvements.

I find this concerning.

I consider it everybody's job to always be on the lookout for ways to improve things.

Not that people should be spending a lot of dedicated time focusing on looking at and evaluating alternatives, but that everyone should have an awareness of challenges and opportunities for improvement and should share these when appropriate.

Many years ago, after the weekly developer team meeting at a company I was about to leave, someone else on the team asked why I had suggested a change to a process in that I'd be leaving in a few days.

I made the suggestion because it would be better for everyone working there. Even if that only included me for a few more days.

That other person was happy to be told what to do and then do it. No questions asked.

I don't want to work like that (and probably wouldn't last that long in such an environment.)

Why UI code matters

As a simplification, there are three types of software:

1. Client/frontend
2. Headless/backend
3. Embedded

(Sure, there is some overlap and some things straddle these loose definitions.)

What separates client/frontend software from the others is that it has a graphical user interface (GUI).

I'm a big fan of GUIs.
I like that they make software easier to use because I can see things and don't have to remember as many options, commands, or a set of seemingly magic words to get the software to do what I want.

For many, many people, GUIs make software possible, usable, and desirable.

However, for many developers, creating GUIs can be a source of frustration.

Regardless of whether using markup to describe the structure of the code or an imperative language that describes how to create it, GUI code can easily become verbose and hard to maintain.

If code is hard to maintain it becomes slower and therefore more expensive to modify without unintended consequences and negative side effects.

If spending extra time modifying hard to change code that means less time for doing other work. Such as fixing bugs or adding new features.

There are also the negative emotions and blows to motivation developers feel about having to work with hard to maintain code.

The GUI is also important as it's the part of the application that people (users) see and interact with. It's what many people will know as the face of the application that they may spend hours looking at each day. They may spend more time looking at it than other people or the faces of their loved ones. For something that gets that much time and attention from the people using the software, doesn't it deserve adequate consideration from a development perspective too?

It can be easy to dismiss the GUI as less important than other parts of a code base, but doing so is a mistake.