When I first learned Java, I set to work creating a chatroom program.

Mind you, I didn’t have any other friends who could run this program on their computers, so there was literally nobody to chat with.

I also didn’t know how hard it would be. I used AIM every day, I thought - how complicated could it be?

I ended up writing what I now know as a new protocol. I used Sockets and Streams and wrote parsers for commands that would be issued over these streams and interpreted by the chat software.

I didn’t know it was hard, so it didn’t feel hard. I just figured it out. There was nobody to tell me I was naive or stupid for trying to build something that complex, that early in my career. I didn’t know any better.

This sentiment has many echoes in the world, the most famous of which may be Jobs and Woz: when they made the Apple 1, they weren’t trying to start a computer company; they were just trying to get a computer. If they could’ve gone out and purchased one, they would have.

Sometimes a bit of naivety is healthy.

thedailydeveloper.substack.com

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com

Wilson sat across from me at one of my early programming jobs. I remember when someone would walk up to him, in person, usually stressed out, and urgently describe to him an issue they had encountered with the software.

What did Wilson do? Did he fume? Did he throw a temper tantrum at being interrupted?

No, he smiled. Smiled! He smiled and wrote down everything they said and told them that he would do his best to figure out the issue. Sometimes he’d ask a few clarifying questions.

Then he would get back to work.

Be Wilson. Be cheerful when someone interrupts you to report an issue. They’re giving you a gift to make your software better.

https://thedailydeveloper.substack.com

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com

When faced with a challenge, we all default to use the tools we know.

For so many of us, that’s code. Whether it’s needing a new blog, a solution to a parent’s tech problem, organizing photos, needing a personal organization system, or thousands of other examples, so many times we reach for software.

I remember the first time I met someone who, faced with a challenge like setting up a marketing blog or whatever, instead of writing code, would write up a job description and hire someone to fulfill the job. It blew my mind.

My brain immediately went into cost/benefit mode. Surely hiring someone is far slower, more expensive, and risky?

Actually his solution was better. The job got done, and it got done quickly. He delegated effectively, giving them context and control of the project. And it didn’t take much of his time.

If I had used the tools familiar to me, it would’ve taken my time away from other valuable projects. It would have probably gotten done halfway, then I’d get distracted by some other more important thing, so the whole thing would’ve taken longer. And, in pure dollars, a software engineer’s time is usually more expensive than a marketing manager’s time.

Be mindful of the tools that you know, and how that selection of tools influences your work.

That’s your Daily Developer meditation for today. Just a reminder that we publish to Substack every day, so be sure to subscribe to receive your Daily Developer meditation direct to your inbox.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com

Early in my career I worked closely with an extremely experienced engineer on a python project. I was headstrong and egotistical about how great my code was. He was quiet and unassuming.

Guess who wrote better code?

One time while I was observing him write code, I was struck by how much his version control system was interwoven into his entire process. After writing or changing a piece of code, he would constantly switch back to his terminal and look at the diff. Many, many times. He would make small commits, even within a file (git add —patch) approximately 100 times more frequently than I ever would have.

At first I thought this was pretty strange, but after working with him for awhile, I realized how liberating it was. I copied his behavior without really understanding it, and I’m very glad I did.

There is a sort of cognitive load that was lifted from my shoulders. Increasing my discipline with my commit strategy exposed all of the gaps in my knowledge of my tools and it increased the clarity with which I could hold my code in my head.

Give it a shot sometime - make your commits more often than you think you need them. Observe how it affects your work product.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com

Tension is required to make something wonderful.

Whether it’s a difference of opinion, perspective, or passion, the combination and debate between and amongst differences makes for a diverse garden of ideas.

Someone once explained this to me using the analogy of erecting a circus tent: in order to put a big tent up for everyone to enjoy the show, you must apply tension in exact opposite directions for the roof of the tent to raise. These forces need to be balanced, otherwise the tent won’t go up, it will flop to one side.

Next time you find yourself or your colleagues debating at work, remember how important it is to balance the tension.

That’s your Daily Developer meditation for today. Just a reminder that we publish to Substack every day, so be sure to subscribe to receive your Daily Developer meditation direct to your inbox.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com

In my first day on the job, I was tasked with synchronizing our python application’s user accounts into our support software via their API. Easy enough, I thought.

Like a disciplined engineer (I thought), I created a new sandbox account to test this API integraton against. Ran the thing like 100 times, fixing bugs along the way.

About an hour later, I got a message from our CEO informing me that all of our customers had been getting hundreds of email invitations to the support desk.

Whoops.

Turns out, sandbox wasn’t so sandboxed. How could I have known?

This lesson is marrow-deep for me. Always, always double check external services (and development vs. production email configuration for good measure) when running them with production data. (Better yet, don’t use production data.)

Luckily I got ahead of the problem and proactively wrote out an email that could go out to the affected customers. My manager appreciated that and, honestly, who hasn’t made a dumb mistake like this early in their career? I’m appreciative that they were so supportive.

Check and double check everything when using external services.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com