If You Can Lean, You Can Clean

With the inevitable slowdown in new projects that comes around during the holiday season, I was reminded of a saying I heard several years ago (attributed to Ray Kroc of McDonald’s fame):

If you've got time to lean, you've got time to clean.

As I touched on in my post on the Boy Scout Rule, I relish these bits of downtime as opportunities to clean up a little.

I always cringe when I hear a colleague say that they have “nothing to do.” Or when a person’s manager inquires about what they’re working on, and the person reports that they’re simply “waiting” for something.

At least as a software developer, I can say confidently that there is always something to do.

• Remove some junk from your codebase (unused files/folders, ancient commented-out code, dead code)
• Update that wiki article
• Change that little thing that’s been bothering you but was too small to take time away from other work

Some of the nicest things are accomplished in small gaps between “real” work.

If you can lean, you can clean.

Be the Automator

In my first job as a professional software developer, the “lead developer” (there were only two of us!) introduced me to a product called CodeSmith.

My reaction to discovering this thing called a “code generator” was disgust. “But…but…I’m the code generator!” I thought. I was incredulous that a professional software developer was promoting a tool that automatically wrote code—the exact thing our employer was paying us to do! It was quite a shock to a young programmer just starting his career. Luckily, code generators were more of a curiosity to him, and we quickly forgot about it. Phew!

Fast-forward a decade plus, and there is nothing I would rather have than a tool that would automatically write all my code for me. Code sucks!

In a sort of ironic twist, I have come to feel strongly that the foremost responsibility of a professional is to make their own job go away. I love working in the field of software engineering, but I also wish we could teach computers how to do it. It can be damn tedious at times.

There has been a lot of talk in the last few years about the future of “jobs” in general. People are facing the idea that jobs lost in the Great Recession may never be coming back. As companies invest more and more into automation, there are entire categories of human labor that might simply disappear in the not-too-distant future.

We folks who make our living in the software industry are at the forefront of automation. I like to joke sometimes that my job is to put people out of work. A dark idea, but it’s essentially true.

Automation is simply inevitable—the benefit of having a machine do a human’s job cheaper, more consistently, with no sick time, and no complaining ever, is too great.

And yet, while being at the forefront of automating other people’s jobs, there are so many aspects of our own work that can be automated. For example, I cringe when I see “QA people” following written instructions while clicking on this button, and then that link, and then typing in foo, and then clicking this other button, and then confirming that this other thing says bar. When the viability of your job depends on your boss never hearing about Selenium, you’re in a bad way. I like to call this “Job Security by Obscurity”. The same goes for developers spending months writing and maintaining their own artisanal ORMs—if Active Record can do your job better than you can, just admit it and move on.

So my career advice to a younger me is this: Be the automator.

Don’t let someone else discover how much of your job can be automated. Find these opportunities yourself and own them. If someone is going to automate your work, it’s going to be you dammit! Teach the stupid computer how to do it, and then apply your working hours to stuff that humans are still way better at.

In the fullness of time, the last remaining “job” is that of the Automator. Be the Automator until there’s nothing left to automate.

A Healthy Disdain for Technology

I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.

If you're programming in PHP, you're not running around talking about "convention over configuration," giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.

Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.

-- swalsh (Hacker News commentor)

I like it when people use rough language toward technology.

Code kinda sucks, doesn’t it? Wouldn’t it be great if there were less of it? Isn’t it a pain in the ass to deal with?

Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it.

-- Jeff Atwood (Coding Horror)

Like many in the software industry, I’m looking on through fingers over my eyes at the horrorshow of front-end web development in 2016.

-Look, it’s easy. Code everything in Typescript. All modules that use Fetch compile them to target ES6, transpile them with Babel on a stage-3 preset, and load them with SystemJS. If you don’t have Fetch, polyfill it, or use Bluebird, Request or Axios, and handle all your promises with await.

We have very different definitions of easy. So, with that ritual I finally fetched the data and now I can display it with React right?

-Is your application going to handle any state changes?

Err, I don’t think so. I just need to display the data.

-Oh, thank god. Otherwise I would had to explain you Flux, and implementations like Flummox, Alt, Fluxible. Although to be honest you should be using Redux.

…

I need to display data on a page, not perform Sub Zero’s original MK fatality.

-- Jose Aguinaga (“How It Feels to Learn JavaScript in 2016”)

Some times it feels like it’s not enough for teams to simply produce valuable software for their customers, they must do so while demonstrating “craftsmanship”, using the most lovingly-curated, artisanal stack of JavaScript frameworks, transpilers, chat tools, NoSQL databases, and text editors.

On the contrary, I believe we need technologists that have a healthy disdain for technology.

Be suspicious by default. Make every framework and tool fight its way in, justifying its existence at every step. Have the courage to say YAGNI to MEAN, blow a KISS to JSX.

And most importantly, get back to shipping great software to your customers.

Humility in Software Development

I think many software projects would end better if we developers would say these things more often:

• No, we can’t get that much work done in the time span you’re suggesting.
• I don’t think we’re disciplined enough to see this complicated feature through to production-readiness.
• We should probably buy a third-party solution for this because we won’t be able to solve the problem as well as they already have.
• This thing is extremely difficult to do well, and you probably won’t get your money’s worth by having us do it.
• You’re too optimistic about this project.
• This requirement is not unique, and we should probably just copy the approach taken by another team.
• There is already a product that does this—you should use that rather than have us develop custom software for you.

Is Your Codebase a Hotel Room or a Home?

I got some strong reactions to a tweet I wrote last week:

Unsurprisingly (thank you 140 characters), some took it as a dig against contractors and consultants. I certainly didn’t mean it that way—many of the sharpest and highest quality developers I’ve worked with in the software industry were contractors or consultants.

The tweet was meant as a dig against companies that routinely staff up a software project with mostly contractors and consultants.

It’s an indicator that the company is taking a short-term mindset with regards to its software.

Now, there are certainly times when taking on a contractor or consultant for a period to augment a software team is a solid choice, for example if there’s a well-defined chunk of work that requires a very specialized skillset, or the team is adopting a new technology and needs someone with expertise to bring the team up to speed.

What I bristle at is the strategy some companies take in which they surround a small core of permanent team members with a swarm of short-term “resources.”

It’s not that everyone who stays in a hotel will intentionally trash the room. But the thing is: they don’t live there. You don’t have to be a bad person to internalize the idea that you’re not going to be around for very long. Short-term gains are rewarded. Long-term plans are left for another day (or another person).

You don’t want your codebase to be a place where most occupants are only passing through. Build a home, not a hotel.

Apple’s Flat Design: When Clarity Goes Out of Style

I’m not the first Apple fan to take notice of the sliding quality of the company’s user interface design in the post-Jobs years.

I remember feeling almost personally betrayed after installing iOS 7 on my phone and seeing the many stark regressions in usability that came with the sweeping visual re-design. Apple had chosen fashion over clarity, jumping on the “Flat Design” bandwagon. This was the same company that built its empire on usability! I couldn’t believe it.

Well, now Nicholas Windsor Howard has written a series of articles that go far beyond my vague unease with Apple’s UI design of the last several years, and provides a detailed examination of many specific areas of decline, including screenshots comparing recent editions of Mac OS X.

If you’re an Apple loyalist who’s lost faith in the company’s once impeccable UI sensibility, Nicholas will articulate your rage. It’s a must-read:

[Decisions] that decrease contrast and visibility—thinner text and glyphs, grey where black once dwelled, delicate borders, less shading—are the unpropitious child of an ideology that puts hunger for novelty, minimalism (of a cold kind), and simplicity (of a superficial kind) above calm rationality, common sense, and empathy for the average computer user.

-- The Apple Goes Mushy

Developer-on-Developer Crime

Recently, I read articles by Mike Anderson and Adam Waselnuk lauding the unusually helpful error messages produced by the Elm compiler.

As you program in Elm, you follow a delicious breadcrumb trail of extremely readable compiler error messages until the program compiles and everything works.

I’m always delighted to hear about developers being kind to other developers by paying close attention to the usability of their tools.

Remember when Rails came along? Remember the tons of repetitive crap that came with doing web development before DHH came along with his incredibly thoughtful open source project that was “optimized for programmer happiness”? (I sometimes think of DHH as the Patron Saint of Dev Tool Usability.)

It’s funny how we computer geniuses go about producing so many tools for other computer geniuses that are incomprehensible to said geniuses.

I think in the current zeitgeist of software development is an appreciation and understanding of the importance of usability, design, and all the details that make software (or websites) pleasant and easy to use. But, tragically, that appreciation for usability tends to go out the window when we are producing software for other software developers.

Think of the last time someone on your team was assigned to automate some task for the rest of the team. Every run of that script came with caveats about which error messages it produced were important and which ones you could ignore. Oh, it’s blowing up because you did X first. You’re supposed to run the script, and then do X.

I think we get lazy on the usability of things we make for other developers because we know they’ll figure it out eventually. We’re so used to diving into the most arcane topics and surfacing days or weeks later with an understanding.

It’s just nice to see those rare instances where a developer went the extra mile to produce something for other developers that was not just powerful, but with special attention paid to the friendliness of the thing. Because, you know, we’re people, too.

Stop Validating Phone Numbers

Ah, the siren song of the phone number field validator…

Can you imagine if you asked someone to write down their phone number for you, and then told them: Sorry, you forgot to surround the area code with parentheses. TRY AGAIN.

Oh, whoops, your phone number has to start with a 1. TRY AGAIN.

The great thing about human beings is that they can deal with ambiguity, while computers are classically ambiguity-intolerant. Unless your software needs to programmatically call the phone number, then why does it need to be in some exact format?

Certain kinds of validations just aren’t worth it, as they do more harm than good. As developers, our job is to help the user, not get in their way.

I can hear developers everywhere screaming: What if they fat-finger the number, typing a ‘w’ when they meant to type a ‘2’!? We must protect them from themselves! Is that any more likely than the user typing a ‘3’ when they meant to type a ‘2’? How is your regex going to catch that?

The point is just to be aware that sometimes resisting the urge to validate is the right thing to do for the user. Think twice before you reach for that regex!

Money Talks

It seems like there is stigma in the software development world around looking at money as a central motivator for one’s career choices. You should instead be passionate about a company’s mission, or motivated intrinsically by a drive toward craftsmanship, or yearn for the chance to use cool technologies.

But there’s a common expression in the outside world:

Money talks, bullshit walks.

It turns out that money is a convenient shortcut to determining how much an organization values one’s contributions. And a close correlate to value is respect.

Even for someone who is not generally motivated by money in life, I believe can still find better jobs by focusing on how much a company is willing to pay.

I imagine many people have had jobs where they felt talked down to or generally made to believe they were unimportant. And along with that attitude comes other negative aspects to a job, like a crappy work environment, outdated equipment, lack of concern for one’s career goals, etc. None of us want a job like that.

If you’ve ever had a job like that, let me ask a rhetorical question: were you well-paid at that job? How was your salary or hourly wage?

Some companies try to get away with lower salaries by offering cheap perks like free sodas and snacks. Similar to car dealerships hoping people will buy a luxury car from them because they offer free car washes.

The thing about perks like that is they assume a certain naivete on the part of employees. “This company is a great place to work, because they have a free pizza lunch once a week…something that costs them a small fraction of my hourly wage.”

Perks are great, but when I find that a company is attempting to sell me on a job by heavily touting these kinds of perks—things that I could buy for myself quite cheaply—I ask myself one question:

“If they really appreciated me and the work I do, why wouldn’t they just pay me more?”

I’d argue that consciously seeking out companies that offer higher salaries and compensation is a great way to find many of the other things that make a job great, like talented co-workers, respect within the organization, and latitude in the way that one works.

When evaluating career opportunities, money is not the only voice, but it sure speaks volumes.

Any Questions for Us?

There was an article yesterday about a software developer who had been turned down by 38 companies and went through 120 interviews in a 2-3 month period, and then finally was hired.

It was framed as an uplifting story about this person's determination that he finally convinced a company that he was worthy of being hired.

I sometimes feel that stories like this perpetuate the "we're up here / you're down there" mindset that some folks take into interview situations.

I'm not the first person to say it, but I believe that as a job candidate, you should scrutinize your interviewers at least as thoroughly as they're scrutinizing you. Many articles about interviewing advice will tell you to ask questions, because it shows interest.

Um...no.

I'm trying to decide if I want to work here or not--that's why I'm asking questions.

CX: Candidate Experience

I’m not the first person to compare technical interviews to hazing—you know, those painful and arbitrary rituals that fraternities and sororities put pledges through because well, they had to go through them, too.

Hiring is hard; we all know that. But just as empathy is at the core of user experience, I believe it’s equally as important to how you treat candidates that are interviewing at your company.

I’m always heartened to read articles and blog posts by software people who are trying to replace the punishing whiteboard hazing that so many tech companies put developer candidates through.

In a recent blog post, Phil Calçado wrote about going the extra mile to improve the candidate experience while hiring at SoundCloud:

But we’ve also done something else. Something that would improve the candidate experience…

With the problem description, we sent to candidates a functional test suite, a binary that when started would try to connect to the candidate’s server implementation, open lots of sockets, sends lots of messages, and verify the results against what the problem description stated. The candidate was instructed only to send their submission once it passed the functional test on their local box.

Now, there is some controversy about whether asking candidates to code side projects for your company at no cost as part of the hiring process is appropriate. But I just wanted to highlight here by choosing the “on your own time” programming exercise as an alternative to the whiteboard grill-session, there are still ways to improve the candidate experience. I’m glad that people like Phil are actively working on this problem, and I hope to highlight on this blog other similar efforts that I come across of people consciously applying empathy to improve the candidate experience.

What Does a Tech Company Look Like?

Many software shops are desperate to mirror the popular notion of how these places operate: loud, boisterous bullpen type arrangements, whiteboards all over with various contrived things on them, street lights flashing the current iteration progress, desks littered with crazy toys and blimps and toy guns, and various nerdly hijinx. It is, in every way, cargo culting, putting the image of how it should work against the actual of how it works.

It looks like what many outsiders think a software shop should look like, all those geniuses doing their genius thing.

Impress investors. Impress potential hires. To the latter most will say "oh no! That wouldn't impress me", but the truth is that real work in this field occurs in the most boring looking way possible, so we all like to imagine that a vibrant office will be an amazing new experience. But in the end we're still wrangling code all day.

- Commentor corresation on Hacker News

Steve McConnell wrote in 2000 about “cargo cult software engineering”—the idea that software organizations often copy superficial aspects of other organizations they admire, wrongly believing that they are the cause of the company’s success.

Here’s a startup that works out of a garage because it’s too broke to afford an office:

Right now, somewhere in downtown San Francisco, a large tech company is designing its swanky new office space:

 

I guess some never leave the garage.

Humane Offices: MathWorks

MathWorks is a name that keeps popping up here and there when I read discussions about tech companies that respect the need for quiet and privacy amongst their software developers.

With headquarters near Boston, MathWorks is the maker of the venerable mathematical computing products MATLAB and Simulink.

I was tipped off to MathWorks when someone left a comment on my post, But Where Do People Work in This Office?:

Here at MathWorks everyone gets their own offices with walls and doors and a small desk and chair for people visiting your office! I love it, it’s very peaceful to work.

Employees mention the private offices in reviews on Glassdoor:

Private offices: collaborate with a co-worker on the whiteboard/computer without interruptions.

- Current Employee - Software Engineer in Natick, MA

Private offices, great tools, many talented colleagues, plenty of opportunities to learn new skills.

- Current Employee - Principal Software Engineer in Natick, MA

From a comment thread on Hacker News about private offices for programmers, MathWorks comes up again:

…the general goal is an office for every full time salaried (non-hourly) employee.

In a thread from the /r/cscareerquestions subreddit:

"MathWorks...[is]/[was] famous for providing private offices to workers."

Check out the open positions at MathWorks here.

Late Night Heroes

This post from Grand Rapids locals, Atomic Object, documents a phenomenon in the software industry that is particularly insidious as it can demotivate good developers.

No one thinks back to the root cause of the pain they don’t feel. There are new problems to solve, new features, or new projects. It’s very easy to miss a critical element of what got you to this point in the first place. Think about it. When was the last time you stopped and appreciated a piece of software that’s run smoothly for years? 

Ironically, less disciplined developers who commonly let bugs out into the world may be more likely to get the technical kudos. After all, they’re performing the software heroics of late night, last-minute debugging and patching. It’s their technical ability that a customer is held hostage to and rescued by. ...these efforts are highly visible to customers. I suspect some developers even get addicted to the opportunity to be a hero and save the day through their technical prowess. This isn’t really in the best interest of customers, but if you’ve headed down the path of undisciplined, unpredictable development, you’re probably thankful for the effort. 

Heroics are great when they’re needed, but it sure is better to not need them at all.

While overtime and late night heroics are highly visible to managers and non-technical higher-ups as extraordinary effort, one might step back and ask, "Why were these efforts necessary in the first place?" Quiet, consistent quality is distinctly un-sexy. It takes place at 2 PM on Tuesdays, not 2 AM on Saturdays.

Why is our software so buggy, our progress so unpredictable? Let's strive to eliminate heroics from our process, not encourage them.

When 10x is 0x

There’s no such thing as a 10x engineer spending time on something that never ends up delivering business value. If something doesn’t deliver business value, it’s 0x.

- Erik Bernhardsson

Ah, the 10x Engineer™.

One of the most frustrating things I’ve witnessed in my career is smart developers working on stuff that just doesn’t matter.

Blistering progress toward a goal that does the business no good, is not progress at all. In fact, when you consider the opportunity cost, it’s negative value.

Perhaps more important than raw technical ability is a finely-tuned intuition about where to aim that talent.