3. Hopes and Dreams are the Fuel

This essay is part of my 42 Deep Thoughts project.

Dreaming and hoping is what gives you the fuel to achieve anything, or get you anywhere; even through the greatest depths of hell.

One of my favorite books, which I go back to every few years, is Man’s Search for Meaning by, Victor Frankel. It’s a book about his observations on how people survived the Holocaust.

Frankel founded the psychoanalytical school of logotherapy, “logos” Greek for “meaning.” Unlike Freud’s idea that the primary force that drives man is pleasure, Frankel’s founded logotheraphy on the idea that man’s primary driver is meaning.

He was developing the concepts before World War II. His observations surviving Auschwitz solidified the ideas. The central idea is that life has meaning under all circumstances, even the most miserable ones.

He observed that when people gave up hope, even if they were healthy, they quickly deteriorated and died in the camp. Whereas the people who held on to hope, had a far better chance of surviving.

I cannot recommend reading this book enough. It is a book that has transformed my life more than almost any other.

Since reading it, I’ve incorporated the ideas into how I live, and achieve things.

I believe that this meaning is manifest through our hopes and dreams. The ideas we hold on to, the picture of what can be, is what propels us forward.

If you’re in a bad place, if you’re not dreaming for a better world, where will you find the strength to find a path out?

If you don’t have a goal, you will never know where you want to be. Looking back, you will be disappointed because you never got to where you wanted.

If you’re not hoping for anything, what do you have to look forward towards?

Hopes can be small, like looking forward to your daily walk through a park at lunch; I used to walk through Bryant Park almost daily while working in midtown. This helped me through some very long days, and complicated projects.

They can be bigger, like envisioning the feeling of acing an interview, when slogging through difficult training material. I worked for several months, working hours every night through problems, during my last round of interviewing. I went being rejected during the first coding interview, to getting through multiple rounds and receiving competing offers from top companies.

Or the dream of working from around the world. This one Ilana and I have been dreaming for a while. It took moving to the countryside, and my getting a remote job for it to happen. But that dream got us here.

Hopes can be giant, like dreaming of returning to the moon. Or solving our climate crisis. Or they dream of peace. Or praying that next year we’ll be in Jerusalem — something my people did for millennia.

Dreams can also be about just getting through another day. Each day is another step, and eventually you’ll get out of the depths of hell.

2. Make it Work, Then Make it Work Well

This essay is part of my 42 Deep Thoughts project.

I came up with this formulation when I was getting into web development, and it’s something I’ve been preaching to every team I’ve managed and worked with.

Perhaps it’s my ADHD, perhaps everyone has this issue, as I was working to build something early on I would tend to get distracted by better ways to get it done. But I wouldn’t finish the project because I kept starting over.

This is also different from the technique of finishing something, deleting it, and rebuilding it again and again. Notice the finishing part there, that’s crucial. That technique is a great way to learn, and build mastery.

There’s a sense that you want your finished product to be perfect. Eventually, perhaps, it should be. But it’s more important to get something done and out there, then to make it perfect the first time.

An analysis paralysis sets in. Whether the project is software, art, even cleaning your house, it’s easy to focus on making it perfect and never actually finishing.

There are several issues with striving to get things perfect the first time.

First of all, especially when learning something new, it can be discouraging to never finish anything. The sense of accomplishment, fulfillment, that you get from creating something powers the learning process.

There will be things you’ll learn along the way about how the finished product should look. Each new discovery will change the way you see the whole solution. Until you have a finished working prototype, you’ll never be able to see what the best option should really be. There will be things you’ll only discover once you see everything working.

Another serious problem with making the first version of your project perfect is that you won’t know how well it accomplishes what you’re trying to accomplish, until it’s done and other people use it.

They say that if your product is perfect when you launch it, you waited too long to launch.

Especially if you’re building something for other people to use, the chances of getting it right the first time are next to nothing.

The tight feedback loop you get from getting something workable out there and used, then perfecting it quickly based on real-time usage feedback, is magical.

This concept is deeply rooted in agile, and lean methodologies.

So when you’re working on something and find yourself distracted by a shinier way of getting it done, don’t stop. Make a note of the alternative path, and push on.

The caveat to this is that once you’ve completed a LOT of projects you will be able to perform at a much faster pace, and sometimes it’s prudent to stop mid-project and start again along another path. Or clean up as you go. But that level of performance only comes with mastery.

If you like this, and want to keep up, subscribe below.

About the image: Creation by Alessandro Dari Gioielli, alchemist.

1. Wear Sunscreen

This essay is part of my 42 Deep Thoughts project.

Originally directed towards the class of ‘97 Mary Schmich wrote an essay which began with these epic words:

“Wear sunscreen.”

“If I could offer you only one tip for the future, sunscreen would be it. The long-term benefits of sunscreen have been proved by scientists, whereas the rest of my advice has no basis more reliable than my own meandering experience.”

I heard this originally as Baz Luhrmann’s version directed toward my class, the class of ‘99.

In truth, it is great advice. As these essays are in the spirit of Schmich’s essay, I thought I’d put my own spin on that advice.

I have rosacea. If I’m out in the sun for too long I get a rash on my nose and face.

When I went the dermatologist to ask about it, she told me to wear sunscreen. “Yeah, yeah, but what do I do now?” I was dismissive.

She responded that sunscreen with zinc, is a cure for rosacea, not just a preventative measure.

I tried it and it works. Also shampoo with zinc like Head and Shoulders helps too. I wash my face with it and it keeps my face clear.

Applying sunscreen is also about planning ahead, and preparing.

Have you seen those pictures of people’s skin, comparing older people who wore sunscreen vs. people who didn’t? Look it up. Sunscreen works.

It also takes a forethought, and a daily habit. You need to make the commitment to putting it on every day. If you do, you’ll be rewarded with younger, healthier looking skin as you age.

Sunscreen also prevents melanoma. Do you really want to die of cancer?

There are so many things in life that work like this; your health is one, saving is another one of them. Several of the upcoming essays will revisit this idea in one way or another, it’s been a powerful theme of my life.

Unfortunately I came to this decision after my dumb teenage years where I worked hard to “condition” my skin to the Middle Eastern sun. I took pride in not needing sunscreen, because I had stopped burning.

Hopefully my youthful transgressions won’t come back to bite me. But for now, I’m wearing sunscreen, and I go to the dermatologist regularly.

And I recommend that you do to.

If you enjoyed this sign up for updates below.

About the image: Photo taken at the Boboli Gardens in the morning.

0. On Being 42, and the Answer to the Ultimate Question of Life, the Universe, and Everything

As a person who is now 42, I feel like I’m supposed to know all the answers.

I remember being nine and thinking that I now have a framework for all knowledge. To clarify, I didn’t think I knew everything, just that I sorta understood how things connected together, and how to fill in the holes.

My parents told me that nine year olds, and middle aged people know everything.

Now that I’m 42, I don’t feel “middle-aged” but according to the definition of “middle-aged” being 40 – 60, I am? So do I know everything now?

No.

But I have collected some tips, personal values, ideas about how the world works — 42 of them, and I’m open sharing.

I believe strongly in cultivating and pondering values, I did study philosophy in college. Oxford defines value as: “a person’s principles or standards of behavior; one’s judgment of what is important in life.”

These are mine. They may not fit everyone. But I do hope that even if one doesn’t fit you, it’ll make you think about things differently.

These aren’t all mine. Some I picked up from other people, and I’ll give credit where it’s due. But I then, I did make them mine. I haven’t added anything to this list that I haven’t incorporated into me.

Instead of writing out a bulleted list of 42 random ideas, that you’ll glance through quickly and then forget, I thought I’d challenge myself by writing out a blogpost about each.

I’ve been wanting to write more here, so here is my opportunity… Or excuse?

Here’s the list: (I’ll update as I write them)

  1. Wear Sunscreen
  2. Make it Work, Then Make it Work Well
  3. Hopes and Dreams are the Fuel

If you want to follow along, subscribe in the footer, and my thoughts will come to your inbox!

Note: (almost) all of the photos were taken my be. Ask me about one if you’re curious.

Yet Another Website Relaunch

Throughout my career I have relaunched this site quite a few times. I’ve used it to explore new web technologies that I can then then leverage on my job.

The first jackreichert.com site I launched was when I moved from Israel to New York. It was a portfolio of the work I had done. I stressed for weeks over getting the site perfect, even after we moved, because New York intimidated me.

The day I updated my LinkedIn profile I was contacted by two headhunters. After three weeks of interviews I landed a job at ISDA.

One time I rebuilt my site I used it to learn how to manage a server myself. Digital Ocean had really great tutorials that got me started. Hosting was safer and cheaper that way, and I got to learn about systems administration. I ended up managing the website servers at work too.

Around the time ReactJS came out, WordPress launched wp-api. I built a React Redux WordPress theme. Then I used what I had learned building that to integrate ReactJS into the new ISDA homepage. Until recently that project was the most starred and forked ReactJS/Redux WordPress theme on github. As of writing this it’s still in 2nd place.

After joining BlueVoyant I wanted to switch up technologies. I switched to Hugo, because I was using Go there. The only thing I paid for was the domain, and it was REALLY fast. But publishing was a pain. I love using my iPad to write, and Hugo really needed a development environment to work well.

In the most recent launch I figured out how to leverage wordpress.com to be a backend for my JAMStack. This way I could use the excellent WordPress app, but could still host it for free.

There are a few pitfalls with this. First, Google doesn’t index single page applications well. Which sucks. I did some things to mitigate this, but it’s not great.

Also, I really want people to be able to subscribe to new posts. I could build something, but that would take time. Which brings me to the reason for my current iteration.

There were times I wanted to learn something non web related, but didn’t have time because I was working on my site. It’s time to finally do that.

This site is fully hosted on wordpress.com. No frills, except for the basic plan so I can use my domain.

I’m paying them so that I can use the time I’d spend on my site to explore other paths of knowledge.

It’s not as beautiful as my previous iterations, to be honest, I was disappointed with the options. It costs double to use custom CSS. What I chose works.

Expect more posts more often now. Some about these new paths of knowledge I’m exploring.

And sign up to the newsletter below!

A Software Engineer’s Guide to Giving Feedback that Actually Matters

Originally posted on Shopify Engineering.

A friend of mine used to get into heated debates all the time. This was before Twitter—well before. Now when you talk to him you would never be able to tell. I asked him to share with me his secret for how he was able to overcome that urge. He told me that he asks himself three questions:

  1. Does this need to be said?
  2. Does this need to be said by me?
  3. Does this need to be said by me right now?

If the answer isn’t a resounding yes for all three, he shuts up.

The idea is that if his feedback will not be heard productively, he simply avoids contributing to the vitriol that fills online spaces today.

Giving poignant feedback is a skill that is not necessarily easy to acquire; yet, it can be a powerful and important tool in a professional organization. Whether you’re providing feedback to a colleague on their work, or managing up and out, it’s important to make sure that feedback will be effective.

This is especially true for engineers working on a team, or a new manager. If you see something wrong in a codebase or architecture, and you don’t say something, you will suffer the consequences and have to deal with an unstable system, or bug fixes for years to come.

You’re also in the trenches with your colleagues. You need to trust them. You’ll spend late nights on deployments and long hours finishing important releases. If someone’s behavior makes it hard for you to work with them, you, the team, and the company will suffer for it. 

If your feedback is productive it leads to growth, both of the individual, and the company.

If your feedback isn’t productive, you’re simply stroking your own ego.

An environment that runs on ego is not collaborative and people prioritize their personal wins over the company’s goals. This creates an unhealthy competitive tension. No one will grow, no one will learn.

It’s easy to fall into the trap of wanting the other person to know that you’re right and that they’re wrong. Especially when you have imposter syndrome, and are plagued with doubts over whether you rightfully belong in your position. It’s easy to want to show that you’re smart and qualified, and belong at your job.

In my experience as an engineer, and in previous roles as a lead, a manager, and a director, I’ve picked up tips for delivering feedback with intention. Throughout this post I’ll share concrete tips and examples that developers are likely to encounter during the pull request review. Then I will show how to leverage these same tools in more general interactions.

Feedback can be a tool that fosters growth and collaboration, or it can cultivate an environment of unhealthy competition. The question is: what sort of environment do you want to work in?

The Pull Request Review

Pull request reviews are great. If you don’t do them where you currently work, you should. A pull request is a way to show what new code you are introducing. A pull request review is a process for getting feedback from your peer before deploying your new code; most systems even let you require one before code merges. When done well, they improve the quality of your codebase, prevent engineers from getting siloed, and are a great opportunity for mentoring. In today’s remote work environment, pull request reviews create a positive touch point between colleagues.

How productive the review is, though, all depends on how effective the feedback is in your pull requests.

We are all professionals and should treat each other as such. So you might think there isn’t a need to worry about the feelings of the other person. However, even if you give good feedback, you’ll undermine its effectiveness if you ignore the fact that you’re speaking to someone else.

Don’t Get Bogged Down in Nitpicks

If you’re trying to give productive feedback in your pull request review, a nitpick will ensure that it won’t be heard. A nitpick doesn’t improve the performance or logic of the code, like a style preference—brace usage or file formatting. While a tidy home makes a happy home, no one likes getting nagged for leaving out the oven mitts.

Bogging processes down over trivialities is called the Law of Triviality, Parkinson’s Law, or more colloquially “bike-shedding.” The term came from Parkinson’s example of focusing on the materials for building the staff bikeshed while reviewing nuclear power plant designs, instead of the actual design of the plant. The design of the power plant is a far more complex, and important design to review. This is as true for your code as it is for the design of a nuclear power plant. Instead of focusing on nitpicks, focus on the critical aspects of the code.

Too many nitpicks is an indication that you have a tooling problem. 

Keeping uniform style across a codebase does improve the quality of the coding experience. Reviewing—and maintaining—code that is a patchwork of styles will lead to missing important things.

But a pull request is not the time to address these issues. A good linter should be able to enforce these preferences. If pull requests are getting bogged down by nitpicks, revisit your linter, consider implementing it in a pre-commit hook. This tool was designed to enforce these opinionated styles, so you should use the linter instead.

Raise the Bar for Your Entire Team

A pull request review is not the time to evaluate the skill level of the other engineers on your team. If you foster an environment where people feel judged and impugned they won’t grow, they won’t excel, and they won’t create excellent products. Remember what I said earlier: if your feedback isn’t productive, you’re simply stroking your own ego, without getting the results you want.

I’m not advocating letting poor quality code into your codebase to appease the feelings of your colleagues. I am advocating that you consider how you’re giving your feedback. Why bother giving feedback that will only fall on deaf ears?

When evaluating code it’s easy to lose sight of the person you’re working with. Writing and reading code requires an analytical frame of mind. Communicating productive feedback takes emotional intelligence. This context switching can be complicated.

So how do you walk that line between giving critical feedback, and making sure it lands?

1. Have a conversation as a team.

Team processes should be reviewed every so often. If you are having trouble with the quality of your team’s code reviews, it’s likely that your team hasn’t discussed important processes in a while. 

Context affects everything. If your team regularly discusses growth, and how to raise the bar for everyone, getting feedback is expected.

2. Frame the context of your feedback.

If you’re doing a pull request review in real time consider prefacing the session with your goals, for example:

“We’re here today to help improve the overall quality of our codebase, help you and me grow in our craft, and prevent you from getting siloed by sharing context.”

3. Write your feedback twice, once to articulate what you want to say, then to craft it as effective communication.

This is a great technique for all forms of feedback, whether comments on code, emails, or Slack messages. I typically use Notepad or a doc to write out longer messages so I can think them over. This way I don’t accidentally hit send before my message is ready.

4. Reinforce the positive too.

Code evaluation isn’t only about finding what’s wrong, but also finding what’s right. Point out where your colleague did a good job too.

5. Ask questions.

Questions are a great way to level the playing field. If your colleague feels like they have something to contribute to the conversation, the pull request review becomes a give and take. This changes the dynamic from one of finding fault, to a two-way educational process.

The ultimate goal of pull request reviews is to lift up the codebase, and the team along with it through collaboration. Keeping this in mind while providing feedback will enhance the process for everyone.

6. Don’t be judge-y.

You’re not here to evaluate your colleague’s skills. You may find areas where they need improvement. That’s ok. But think about how to relay criticism. I’ve recommended videos and articles when I saw that someone needed help in an area. I’ve also asked for resources when I found myself lacking.

7. Make it SMART.

Just like SMART goals, you can frame your feedback in a way that is Specific, Measurable, Achievable, Realistic, and Timely. If your feedback isn’t specific, it’s hard for the other person to address the issue. Givean example. If it’s a general issue you’d like to address in the codebase overall, mention that it’s a larger conversation, and consider not holding up the entire merge request.

8. Separate the person from the behavior.

When giving critical feedback, it’s easy for the recipient to feel attacked. If you separate the person from the behavior it helps the person accept the feedback more easily. They are not being attacked, it’s simply something that they should do differently. For example, instead of telling someone that they’re a sloppy developer, try saying: “When you don’t tophat thoroughly it leads to more bugs that your other teammates have to handle.”

Managing Up and Out

You’d be surprised, but you can “manage” your boss and teammates. Every relationship requires a certain level of cultivation, or managing, to remain healthy. With a close friend, that can mean writing a thoughtful note from time to time. With a spouse, you might go on a date night.

In a work setting you should always cultivate relationships with your colleagues, your reports, your peers, and your supervisor.

When someone does something wrong in the workplace, it’s like a dead fish: the longer it stays hidden under the carpet, the more it smells.

Personally, I seek feedback. I like having regular one-on-one meetings with my colleagues. It helps me stay on track. I know what’s going on within my team, what my peers need from me, and what is top of mind for my boss right now.

Management consultant Peter Drucker defined management as “the organ of society specifically charged with making resources productive.” So regular communication is key for keeping everyone working together productively.

But when something is off—when that dead fish begins to smell—what do you do?

That’s when we ask ourselves my friend’s three questions:

  1. Does this need to be said?
    Is this an issue for you, or is it affecting other people? If it’s only bothering you, maybe you don’t have to say something. Maybe you do.Does this need to be said by me?
  2. Will what I say be heard, and be impactful? 
    Maybe this is something that is better handled by someone closer to the person, or by their manager. If it needs to be said by someone else, but not by you, consider having a conversation with their manager so that the person will get the feedback before it’s too late to improve.
  3. Does this need to be said by me right now?
    Some times aren’t good for giving feedback. Is the person, or team, struggling to get an important project done? Are they dealing with something stressful at home? These aren’t excuses to behave badly, but they may affect the impact of your feedback.

Think about how you can provide feedback that will be heard, and be productive. Can you give a feedback sandwich? Compliment, critique, compliment. Finally, are you giving SMART feedback? Feedback should be framed like goals. They should be specific, measurable, achievable, realistic, and timely.

If you ask yourself these questions, and the answer is yes, you’re likely not speaking out just for your own ego. And if you think about who you’re speaking to and how they will receive what you’re saying, you’re likely to be impactful. And your feedback just might make a difference.

Star of David

This is a Star of David. It is a symbol of pride for my people, adopted by the movement born out of our need for self determination in our ancestral homeland after millennia of exile and persecution — the Zionist movement. The chant of hope my people spoke, during the darkest nights, during pogroms, holocaust, inquisition, and holy wars over millennia was “Am Yisrael Chai” the nation of Israel lives. Chai – life – is the word inside the star.

I purchased this star online from an Israeli Etsy store during the Gaza unrest of May 2021. While my family was sitting in bomb shelters, Hamas rockets were falling throughout Israel, and Jews were being attacked all over the world. One person was attacked for wearing a star. I purchased this star to wear, to express MY pride. The dream of self determination, living in our ancestral homeland, had been fulfilled.

November 2021 I traveled to Jerusalem to visit family. Walking through the center of town a man stopped me, pointed to my necklace, and asked: “Where did you get this?” I told him that I had gotten it on Etsy.

He beckoned me into his store. It was one of those stores you might think is for tourists, as it is. But when you look closely at the wares, each one is carefully crafted, and beautiful. There were handwoven cloths, chessboards, lamps, and bags of all sorts.

At the back was a jewelry cabinet. He pointed down and right there was my star.

He hadn’t heard of Etsy and was worried that someone had stolen his design. So I found my email receipt. He zoomed in on the profile picture of the seller and started laughing “Daoud!” It turns out it was his cousin who handles the online store.

Avi, the person who called me in, was the silversmith who had designed my necklace. The store had been founded by his father. The family are Bedouin, an Arab nomadic tribe, and live near Be’er Sheva in the Negev down south. They have five stores now, all around the country, and the various pieces are all hand crafted by his family.

Avi invited me for to share a cup of Turkish coffee with him and we talked about our lives.

This is a typical Israeli story.

Dignity in Tech

In my senior year of high school I taught myself HTML. That was right after HTML4 came out, and it made more complicated web designs possible. I had to lay out images using tables, but I could still do it. I was learning Pascal in school and took to coding like a dog to a freshly mowed lawn.

I built sites for some small businesses in my neighborhood to earn enough to pay for a plane ticket, so I could travel in the summer, before starting a 5-year conscript military service program in the Israel Defense Forces (IDF).

Years later, I was a senior in college studying philosophy. My wife was a journalist and joined together with a colleague of hers to start an environmental news blog. I volunteered to take care of the tech, since I had done this in high school… sorta. WordPress was the platform they had chosen.

The first time I went to make a change to the theme I broke the site. I quickly ctrl-z’ed and resaved. Thankfully the site was restored. Then I looked at the theme code, saw the loops and variables, and felt right at home. It was just like the Pascal I had learned back in high school.

I built a website for my father-in-law’s business. Once I had a live example, I could find more clients. Suddenly I was scraping together a living. There was a point when I had to go to the bank to beg for an extra few days on a payment because one of those clients was taking their time to pay me. But I still had the money coming in. That was powerful.

One of my clients was a startup and they asked to hire me full-time. From that point on I was able to get jobs at other companies. The first full-time gig is the hardest to land, even if you have the chops.

Jaron Lanier talks about two possible futures (the conversation starts at 43:29). One is a future built on top of our present paradigm in tech, and then there’s another.

He describes that in his neighborhood there are tree cutters who work together to ensure that if there’s a fire, the trees from one property wouldn’t burn down the rest of the neighborhood.

He goes on to say: Imagine if one day a truck pulls up with fun playful colors, and cameras, to observe the tree cutters. A couple years later a robot comes to market that cuts trees and ensures the same innovative processes that prevents wildfires from decimating the neighborhood.

The outcome would be that these tree cutters, who came up with the innovation, would be out of a job. Perhaps, Lanier muses, they’d be taken care of by UBI, but he goes on to explain that throughout history when such systems were put in place they were quickly taken over by only a few people and abused. Additionally, even if the tree cutters were actually taken care of, they would have lost the dignity of being able to support themselves.

Another possible future, he describes, is where that same robot company is formed and also builds a robot guided by AI that can cut trees. But it does so with the help of the tree cutters, and pays them for their expertise. Not only that, but they create a platform where those tree cutters can develop other innovative techniques and sell them to the market of people who buy those robots.

Same tech robot startup, also using algorithms, but a very different future. One future puts people out of a job, and one future creates a bigger pie, a platform that spawns an industry where people can support themselves through creative ideas, their own innovations. Maybe those tree cutters’ next innovation is beautiful tree arrangements, or maybe they tackle climate change.

There is so much creativity in tech and there’s a lot of opportunity for disruption.

The steam engine was the first time we were able to separate muscle power from muscles. The invention of written language let us separate knowledge from memory. And computers have let us separate computation from our brains.

With all this leverage so much can be done. But it’s important for us to think about how we disrupt.

We can invest in replicating the wisdom of experience, and replacing it. Or we can harness that wisdom by empowering those with the wisdom, and create opportunities for further development of that wisdom, at scale.

I have a successful career thanks to WordPress. They built a platform that others can build upon. People support themselves by building websites, themes and plugins for people who run websites. Entire companies are built around hosting these sites. Much of the sites hosted on WordPress are companies themselves, who can afford to have a professional site at a fraction of the cost of having a web team to maintain a custom CMS.

WordPress, as a very successful company, makes money by doing all these things too: hosting, security, apps, themes. There’s room for everyone because they created a platform for innovation, not a limited pie.

Now I work at Shopify. I’m very proud to work here. They have a reputation for excellence, and I’m proud to have reached where I have — an entrepreneur and self-taught engineer — that a company of such a caliber wanted me.

But I’m even more proud of what Shopify does. They’ve created a platform for people to build livelihoods on top of. They’re expanding the pie.

Their core mission is to make commerce better for everyone. Anyone who has an idea can sign up and have most of the hard things around running a business taken care of. Shopify has millions of merchants building businesses on its platform.

They have also built a platform/marketplace, like WordPress’, for themes and apps. Anyone running a business will need a great looking site, and specialized functionality in that site. People, like younger me, can build their career on top of that. All you need is an idea that makes running a business better, and you don’t even have to compete with Shopify. They provide the ability to sell your idea directly to the people who will benefit.

They’re expanding that pie, like the robot company who partnered with the tree cutters. I’m proud to be a part of that.

Image: Mt. Mauna Kea Summit Observatories

A Year of Shakespeare

I spent this past year reading all the plays of Shakespeare. Each has five acts, a play runs 2-3 hours, an act can be read in 30-45 minutes. There are 38 plays, so you can read a play a week and finish well within a year.

I spent most evenings reading an act, often listening to a performance while reading to enhance the experience, and help out with some of the more difficult ones.

As an homage to this past year I collected some quotes, full and partial, which I composed here in a nonsensical manner. After spending a year with him, I feel that the bard would approve. Enjoy!

* * *

First my fear; then my courtesy; last my speech.
My fear is, your displeasure; my courtesy, my duty;
and my speech, to beg your pardons
(Henry IV p2)
Now, by my faith and honour, If seriously I may convey my thoughts
In this my light deliverance, I have spoke
(All’s Well)

Friends, Romans, countrymen, lend me your ears! (Caesar)
Open your ears; for which of you will stop
The vent of hearing when loud Rumour speaks?
(Henry IV p2)
Mine eyes smell onions
(All’s Well)
All that follow their noses are led by their eyes but blind men; and
there’s not a nose among twenty but can smell him that’s stinking.
(Lear)
With spectacles on nose and pouch on side,
(As you like it)
I prithee take the cork out of thy mouth, that I may drink thy tidings.
(As you like it)

The tempter or the tempted, who sins most? (Measure)
Good friends, sweet friends, let me not stir you up
To such a sudden flood of mutiny.
(Caesar)
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
(Hamlet)

My Genius is rebuked; as, it is said, (Macbeth)
If music be the food of love, play on;
Give me excess of it, that, surfeiting,
The appetite may sicken, and so die.
(Twelfth Night)

O for a Muse of fire, that would ascend
The brightest heaven of invention,
A kingdom for a stage, princes to act,
And monarchs to behold the swelling scene!
(Henry V)
Whose golden touch could soften steel and stones,
Make tigers tame and huge leviathans
Forsake unsounded deeps to dance on sands.
(Two Gentlemen)
If all the year were playing holidays,
To sport would be as tedious as to work;
(Henry IV)

Go, sirrah, take them to the buttery,
And give them friendly welcome every one:
(Taming)
I am sent with broom before,
To sweep the dust behind the door.
(Midsummer)
Since every Jack became a gentleman,
There’s many a gentle person made a Jack. (Richard III)

Quality First

What does that mean?

It means that I get grumpy if I need to keep waking up because something wasn’t built well. But if you want to ignore MY feelings, you can bet that your customers will feel grumpy too if they need to use your service and something isn’t working.

In short:

You want the tools that you build and use to be reliable, and maintainable.

Reliable Tools

This means that your tools, internally built or 3rd party, consistently do what you expect them to do.

The only way to truly ensure this is to have test suites built around your code bases. Unit tests ensure each piece does what you need. End to end (e2e) tests ensure the entire project does what you need. Integration tests ensure that 3rd party tools continue do what you expect them to do.

There are many other tests can be leveraged to ensure reliability, these are a few that you should start with.

You also need to know when things aren’t working the way you expect them to work. This means building monitoring and alerts into all the tools you build, and around all the 3rd party tools you use.

Both the test suites and the monitoring should be planned and designed along with the design process of the feature. If you’re not planning for it from the beginning you will likely cut corners, and then you no longer have reliable tools.

Maintainable tools

This means two things. First, that it’s easy to fix when things go wrong, and second, that it’s easy to add features when we need them.

To achieve both these goals it requires more thought, and planning, up front.

When new features are requested there is often pressure to get the feature out as quickly as possible. At a startup, that speed is especially important for success. But we do have to factor in the time we’ll need in the future to make the new features maintainable. It may take a future iteration to do this. The cost, however, of not iterating is that the next feature will take longer to implement. And over time your project will grow stale and unworkable.

Maintainability is achieved through adhering to our best coding practices, as well as regular reflection back on past features in order to find ways to improve them.

Share Knowledge — Don’t Silo Developers

Another part of maintainability that is often overlooked is ensuring that there is expertise and a sense of ownership shared by multiple team members.

Part of achieving this is by ensuring the codebase is clear, well documented, and readable code, that is well structured and does what you’d expect it to do — see the book Clean Code.

However, just as important, is making sure that multiple developers get a chance to work in the codebase. If only one person on the team has developed an important feature or project, what happens if it breaks and they’re out? What happens if there is an urgent feature, but that one developer is on another urgent feature?

When one person does the bulk of the development they own the project, but they’re alone in that ownership.

Pairing on developing and planning out projects ensures everyone has ownership. Managers may complain that pairing slows the team down, from my experience, when it’s done regularly it does not. Whatever time is lost on sharing knowledge is gained with more heads able to work on problems.

When developing features, if the stories are smaller, then more people can pick up pieces of the project or feature, and gain ownership and expertise. The cost is small while one developer gets up to speed mid-feature, but again, that is gained back with more heads with ownership over the project.


A quality first mindset is about making sure that the tools you use are reliable and maintainable. It’s often tempting to sacrifice quality for speed, and truthfully, if your v1 isn’t embarrassing you’ve probably waited too long to get your tool in front of customers.

However, as you grow your tools, it’s important to implement a discipline that will ensure the longevity of your tools, ensure that you, and your customers, can rely on them.