Skip to content

All posts by moore - 4. page

Books and other resources to level up as a software developer

A while ago there was an HN post asking for suggestions on [r]eading material on how to be a better software engineer.

Here’s my list based in part off a comment I made there.

First, books:

  • Secrets of Consulting by Gerald Weinberg because every problem is a people problem.
  • Refactoring by Martin Fowler et. al. discusses how and why to refactor, as well as providing a nomenclature for the process.
  • Code Complete by Steve McConnell is a bit dated (the last version I could find was from 2004) but a great overview of the entire software process, from requirements to maintenance.
  • The Mythical Man-Month by Fred Brookes covers best practices about software development, written about a project from the 1960 and 1970s. Nothing new under the sun.
  • The Joel On Software Strategy Letters cover different aspects of software strategy. The link is the first one, but all of them (I think there are five) are great.
  • Letters to a New Developer is a collection of essays helpful to new developers. Note I wrote this book, but I think it does a good job of discussing the “soft skills” in an easily digestible format.
  • The Pragmatic Programmer by Dave Thomas and Andy Hunt. I haven’t read the revised 20th anniversary edition, but the first one opened my eyes to the craft of software.
  • High Output Management by Andy Grove illustrates how think about throughput.
  • The Phoenix Project by Gene Kim et. al. is a fun novel(!) about applying lean management principles to software engineering.
  • Good to Great by Jim Collins focuses on what great companies bring to the table. Helps me evaluate where to work.
  • Managing Humans by Michael Lopp. The whole Rands site is worth reading, but I enjoyed this book about how to manage teams and build software. See above.
  • Don’t Make Me Think by Steve Krug shows ways to think about usability, focusing on webapps. Short and easy.
  • Badass: Making Users Awesome, by Kathy Sierra helps you put yourself in the shoes of your users and think about how to build software they will love. Short and easy.

Then, podcasts and videos:

  • Mastery Autonomy and Purpose, a great video about what people really want in work.
  • The Manager’s Toolbox podcast, focuses on nuts and bolts skills for managing people. You didn’t say you wanted to be a people manager, but knowing what managers think about will make you more effective in any org.
  • Screaming in the Cloud is useful for keeping up with AWS and other cloud provider offerings.
  • SE Radio is a bit dry, but has a great back catalog of software engineering focused episodes.

A few other resources:

  • The Rands Leadership Slack has over 10,000 engineering leaders discussing all kinds of software related topics.
  • CTO lunches is an email list of engineering leaders. The discussions aren’t consistent, but when they happen, they’re great. Plus, it comes to your email.
  • HackerNews is a great way to burn time, but also a great way to keep on top of topics that are top of mind of some of the best developers in the world.

Reading up on software practices can help you level up as a software engineer because you’ll be able to avoid mistakes others have made before you. I can also offer a view of the big picture; knowing how your software helps your organization or company will only make you more valuable as a developer.

Business Programming Technology | moore |

Consulting tips

If you are thinking about making the move from being an employee to consulting, I have some thoughts. First, there is a difference between contracting and consulting. Contractors are paid for what they do, consultants are paid for what (and who) they know. I have found it’s a lot easier to get contracting work than consulting work. (Of course, sometimes they blur together.)

If you are focusing on consulting, think about:

What is your source of work? Finding work is a big part of consulting. Options include:

  • your network (it’s fine to hit folks up and say “I’m doing X, do you know anyone who needs it?”)
  • past client
  • courses
  • a community presence
  • books
  • blog/writing
  • advertising (though this can be easy to waste money on if you aren’t targeted)

I’m sure there are others. Think about and nurture this pipeline. Always ask happy clients for referrals. This is something you typically don’t think about as an employee (it’s someone else’s job). It’s part of your job as a consultant.

How will you get paid? This is the other piece of consulting that people jumping from employment don’t consider enough.

What will your terms be? Have a standard contract. Have buffer in the bank because there will be lean months; prepare for “feast or famine”. You’ll also need to be prepared to chase down payment. Doesn’t happen often and you can prioritize companies that pay promptly, but with what feels like an economic rough period ahead, companies will be stretching payment terms, esp to outside consultants.

Don’t expect to be paid when you do the work, 30 days net is typical. Use a solution like freshbooks (what I used, years ago, there may be better ones) to automate your invoices and possibly invoice nagging.

Sometimes you will be paid to do things that seem dumb and/or below your pay grade. Raise your concerns, but if you are told to continue, smile and do it. One of the joys of consulting is you are not really “one of the team” which can give you healthy separation from org problems you aren’t trying to solve.

You are not really “one of the team” with any of your clients. Esp if you are a one person show, this can be lonely sometimes if you are used to socializing with your coworkers. Not that they won’t invite you to lunch, etc, but there’s always an awareness that you are a hired gun rather than someone who is on the team. (They might try to recruit you, though. Be prepared for that.)

Taxes/ownership structure/insurance become a bigger thing. Find a CPA, preferably through a referral, and understand and set up the proper ownership structure and tax payments. Typically your tax burden will be higher, but you can write off more stuff as a business expense. You may need some kind of business insurance depending on who your clients are (Oracle made me get e&o, I carried general liability for a while). The nolo books are good on this if you want to get smart on your own, but you’ll really want a CPA in your court.

Think about if you want to be a one-person show or build a team? I personally never got past the one person show stage (though tried subcontractors a few times) because I didn’t want to manage and I wanted to do the work. If you are building a team, you will need to focus even more on bringing in work rather than doing it.

Consulting can be fun because you have control of your work and you get to work in different environments without switching jobs. It’s also more stable to have a few purchasers for your labor than just one (an employer). Think about what kind of work you want to specialize in, because the temptation (esp if cash flow is low) will be to take anything you can do (or maybe things you think you can do).

Spend time on professional development. That could be during the work day or after hours. Sometimes clients that know you will pay for you to learn something, but that is not typical in my experience.

If you have the time, create a course or ebook in the domain you are planning to consult in. This can give you some income, but the real benefit is to say “I wrote the book on X” or “I did a course on X”.

Think about passiveish income options. Courses or ebooks (as above) can offer that. So can productized services, web hosting, or access to a tool that codifies your knowledge. Don’t focus on this when you start, but having something like this will help buffer your cash flow.

Prepare to raise your rates yearly and with every new client. No one is going to give you a raise, you have to ask for one. I usually said something like “my new rate for next year is going to be X/hr, please let me know if you have any questions” in an email around this time every year. Be prepared for some clients to not be able to afford you, and to part ways.

Finally, some book recommendations:

  • The Secrets of Consulting is required reading, covers about the people side of consulting which is really critical.
  • Value Based Fees: How to charge value based fees rather than time and materials/hourly/daily. I never had the guts to do this, but it was eye opening to read about.
Consulting | moore |

GitHub Actions Are Amazingly Easy

GitHub Workflows are automated jobs that can be triggered by various events against a GitHub repository. They are pretty awesome.

GitHub Actions are a way to encapsulate configuration and functionality in a way that can be easily reused in GitHub Workflows.

I was thinking it’d be fun to create some GitHub Actions (yes, I’m the life of the party), so I sat down a few mornings ago to do this. I was shocked at how easy it was.

I followed a few lines of this tutorial to create a workflow. Then I created an action by following this tutorial. Finally, I edited my workflow to use the new action. That was it.

It was amazingly simple and took me about 30 minutes. I ran into one unrelated issue (to set the executable bit on a shell script in windows, I had to modify the shell script contents in order to ensure the change was sent to the remote repo).

If you take a look, you’ll see these are both toy repositories, to be sure. However, the ability to write jobs which will be executed on a git push, pull request or other events is great and removes toil. Being able to extract common functionality to an action is even better. Finally, the ability to share the action publicly by adding it to the GitHub marketplace is fantastic.

I’ve liked CircleCI for a long time, but if I were them I’d be worried.

One issue I found is that the testing/release cycle is pretty tedious (I’ve mentioned that action debugging to be an issue for a while).

While I was troubleshooting my executable bit error, I had to do the following every time I wanted to test a change:

  • make a change in the action repository
  • create a new tag
  • push it to the remote
  • switch to the workflow repository
  • bump the action version
  • push to the remote
  • wait for the workflow to complete

Not horrific, but pretty tedious. I don’t know if there are other options such as local deployment which would reduce that cycle, but that would be swell.

Other than that, 10 out of 10, would write more actions.

Devops Programming Technology Tips Useful Tools | moore |

How To Start Improving a Legacy App

An interesting question appeared on HN recently: “Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?”

You can read that post and the answers there. I’m going to address a related, but different question in this post.

If you run encounter an application that has tremendous business value and yet is not following any modern software management processes, what are concrete steps you can take to help improve the application?

That is, what if you have (or are hired to be responsible  for) an app like the poster of the HN thread:

  • making plenty of money for the company
  • no version control
  • old school structure
  • a ball of mud architecture
  • no code deleted, just commented out
  • multiple versions of libraries on the front and back end
  • etc

First off, you need to convince someone that it is going to be worthwhile to invest in this process. If you can’t do that, you are dead in the water. So look for the pain points that occur when best practices are lacking:

  • slow delivery of features
  • catastrophic bugs which lose money, hurt the brand or impact data
  • talent hard to hire
  • hard to improve the application

If you can pinpoint pain caused by the app, you can start to build a case to improve it.

If you can’t, well then, maybe you shouldn’t touch it. If it ain’t broke, don’t fix it!

With that said, here’s my list of what to implement, in rough priority order. Don’t worry about best of breed for the tools, just pick what the company uses. If the tool isn’t in use at the company, pick something you and the team are familiar with. If there is nothing in that set, pick the industry standard. I include a recommendation for the latter.

1. Get the app under version control. Git is best if you don’t have any existing solution. GitHub or GitLab are great places to store your git repositories.

2. Start up a bug tracker. You have to have a place to keep track of all issues. GitHub issues is adequate, but there are a ton of options. This would be an awesome place to get buy-in from the existing team about whichever one they prefer. The truth it is doesn’t matter which particular bug tracker you use, just that you use one.

3. A way to get one click or zero click deploys. A SaaS tool like CircleCI, GitHub actions is fine. If you require “on prem”, Jenkins is a fine place to start. But you want to be able to deploy changes quickly.

4. Set up a staging environment. With one, you can manually test changes and debug issues without affecting production. Building this will also give you confidence that you understand how the system is deployed. Then you can can include that in the build tool process.

5. Unit and system/end to end testing. End to end testing can give you confidence in changes. However, it is overwhelming to add testing to an existing large, crufty codebase. I’d focus on two things: unit testing some of the weird logic; this is a relatively quick win. Second, setting up at least one or two end to end tests through core flows (login, purchase path, etc). In my experience, setting up the first instance of each of these is the toughest process, then it gets progressively easier. There’s usually an ‘xUnit’ framework in any language for unit testing. Look for that. I’m not sure what best practice is in end to end testing, but selenium or cypress are good for browser based applications.

6. Capture documentation. This might be a higher priority, depending on what your relationship with the existing team is. Few teams will say no to someone helping out with doc. Document high level architecture, deployment processes, key APIs, interfaces, data stores, and more. Capture this in google docs or a wiki if you don’t have an existing solution.

7. Start using data migrations. Having some way to automatically roll database changes forward and back is a huge help for moving faster.

None of these are about changing the code (except maybe the last one), but they all wrap the code in a blanket of safety.

After implementing one or more of these, the team should be able to move faster and with more confidence. This will build trust and allow you to suggest bigger changes, such as bringing in a framework or building abstraction layers.

Consulting Programming | moore |

What in-person conferences offer: feedback

I was listening to a Twitter space recently and the host had an interesting take: for the amount of money you would spend flying a speaker to an international conference (call it $5000, though of course the actual number varies depending on location, timing and more), you could record a great educational video and get it in front of many folks on Youtube.

Assume you spend $3000 on video production, and the CPM is $4 (hard to find solid numbers, but this post talks about rates in that range), you could put that video in front of half of a million people (1000 views/$4 * $2000). That’s a big number, certainly more than attend any conference.

As someone who is gingerly stepping back into work conference travel, who doesn’t like to spend time away from his home, who is a member of the flyless community, and who came into devrel in earnest during the pandemic, I’m sympathetic to that view point. It is more efficient to broadcast your message wholesale, whether that is with a blog post, webinar, or a video, than it is to talk to people retail at a conference booth, or even to give a talk to a hundred people.

But what I’ve learned is that there are real benefits to in-person conferences too: attention, prestige and feedback.

Attention

Think back to the last video you watched, especially if it was technical. How much of your attention did you give it? Perhaps 100% if following a tutorial. But perhaps substantially less if it was background noise or you were looking to learn a bit on the subject.

I’ve definitely “attended” online conferences where I was not paying attention. And I have never popped into a virtual conference “booth”, so I have no idea if the content there is compelling.

I’ve also seen folks at in-person talks on their phones or computers, to be sure, but it is not the rule.

Data is hard to come by, but I believe that folks that are more likely to pay attention at an in-person event. They have made more effort, so they are more committed (research finds “working hard can also make [things] more valuable”). There’s also more distance from the normal work task during an in-person conference. Attendees have far fewer distractions, and an expectation of attention. I think that focusing your attention on a speaker at a talk you are attending is the polite thing to do as well, and there are social norms pressuring folks to do that.

This attention makes an attendee at an in-person conference more valuable than a Youtube viewer.

Prestige

While not anyone can create a great video, anyone with a camera can make a video.

On the other hand, not everyone can buy a booth at a conference, attend one, or speak. There is a filter on everyone who is at an in-person conference. This filter disadvantages folks who can’t travel, have a disability, or have other constraints. But it improves the value of an interaction at a conference too.

Being able to pay for a booth or have a talk accepted in particular are signals of quality. They don’t equate with quality, as anyone who has sat through a vendorware conference presentation can attest, but there is some level of prestige that accrues to an organization by being at a conference. That’s one of the reasons companies pay to sponsor conferences; there’s value in being seen there. (Others might phrase it differently.)

Feedback

Feedback is the last, and in my mind, most valuable differentiator between in-person conferences and online educational activities.

At a conference, the opportunity for two way communication abounds!

Any time someone stops by a booth or asks a question after a talk, as an educator you have the opportunity to not just answer a question or address a comment, but to dig in and understand the person’s context. What do they do? Why are they asking that particular question? Is there an unstated assumption in their question?

You can and often do have ten minute conversations at a booth, and this qualitative, high bandwidth feedback from expensive software development professionals is valuable in learning about your market and seeing if your message resonates.

Contrast that with the limited q&a at an online conference or the comments on a video. Yes, that is also feedback, but it is far less nuanced, considered, and interactive.

Conclusion

The ready availability of high quality, intense feedback driven by back and forth communication is the killer feature of in-person conferences. I don’t see any way to replicate that right now online.

Conferences Devrel | moore |

AWS Compute Savings Plans

I was doing a project for a hackfest at FusionAuth recently (big fan of hackfests and have been for years).

I was looking at ways to decrease our hosting bill (we host with AWS). There are, of course a variety of ways to accomplish this, but I spent some time looking at EC2 savings plans and RDS reserved instances.

After the short presentation I gave at the end of the day, someone asked “What about Compute Savings Plans?”

I looked at them briefly and they seem like an no-brainer.

With this option, you commit to a certain amount of compute spend (any amount you choose, basically) for a certain period of time (one year or three years) with a certain payment plan (all up front, partial upfront, or no upfront). Then AWS gives you the discount in exchange for this guaranteed income.

Plans are controllable via API and purely a billing construct. Being on a plan doesn’t affect the performance or availability of your compute resources. This is unlike other ways to save money such spot instances.

A Compute Plan, notably is not tied to a region, compute option, or instance type. It covers hours spent across EC2, Lambda and Fargate. It’s quite broad. Other options tie you to a region or a instance type family.

Therefore, this seems like an obvious choice to save money while retaining some flexibility, such a key selling point of the cloud.

Anything this obvious raises suspicion in my mind. So I thought I’d look at it the other way and consider why you wouldn’t use a Compute Savings Plan. Here are the reasons I thought of:

  • First, you might not know about it. I didn’t. Hopefully this blog post does a small bit to educate you.
  • Second, you might not be running anything on AWS EC2, Lambda or Fargate. In that case, a plan is useless, of course.
  • You might have highly variable compute needs, which frequently go to zero. In this case, committing to a certain number of hours a year might not be worth it. It depends on how many hours a year you will use and what the savings might be.
  • You might be planning to depart from AWS for any number of reasons. Depending on how serious you are, you could lose money with a commitment to a plan. That said, most migrations take longer than you think. You can probably lower the amount of commit to the point where it makes sense.
  • You don’t have the money to pay upfront. In this case, you can still use the “no upfront” option and save some money. Less, but still some.
  • If you have extremely stable compute needs, you can use Reserved Instances or EC2 Savings Plans (or, frankly, other hosting providers offering less flexibility, such as data center providers) to save more money. Totally possible, but I haven’t run across it. I’ve heard tell of them, though.
  • You prefer Amazon to have your money rather than you. If this resonates and you are open to changing who you give your money to, please contact me. I can use more money.

What am I missing? Are there other reasons why a Compute Savings Plan for AWS is not a good idea?

Finally, here’s more information from The Duckbill Group about Savings Plans, in particular how the savings are calculated and applied.

AWS | moore |

Collecting internet points

I’ve been pretty active on HackerNews for the last couple of years and recently made it into the top 100 posters. According to this stats page, in just over 10 years as a member, I’ve posted 3468 comments and had 7824 submissions. That is approximately 1 comment and 2 posts per day, for a decade. (The numbers are as of the time I write this post.)

That’s a lot of hours on a site.

In light of that effort, I’d like to reflect on the good, the bad and the ugly of my years on HN, collecting karma points.

The good:

  • It’s elevated worthwhile posts and sites. I don’t know a single better source of free traffic for technical content. You don’t just get the initial traffic; other sites, online communities and newsletters pick up top ranked HN posts and reshare them, so there’s an echo effect as well that lasts for weeks. It is really fun to find a good article, post it and surprise the author.
  • I’ve learned a lot by reading the comments, especially in fields outside of software engineering. Posts on topics such as economics, physics and careers all receive really insightful comments.
  • I’ve been able to help a few folks get jobs by posting on HN. They have a monthly free jobs board and I know at least two people who have been hired because of one of my posts on the jobs board.
  • While trending on HN doesn’t typically translate directly to sales, it is great for brand awareness. At my current job, quite a few sales processes have been started because an engineer read a post about FusionAuth on HN.
  • For a developer relations position, having an active presence on HN is helpful. You can certainly devrel without being on HN, just like you can devrel without being on Twitter. But in general a public profile is helpful.

The bad:

  • While most folks argue and discuss from a place of goodwill, there are some who are overly pedantic and or just not nice. I can ignore them, but I remember a few flushes of shame where I made a mistake in a comment and was called out on it in an unkind, direct manner.
  • Self-promotion is part and parcel of a community where there’s this much traffic (to be transparent I promote my own stuff, but only 1 out of 10 posts at most). Often, I’ve seen over the top self-promotion. If someone only posts their own content, it simply doesn’t work.

The ugly:

  • HN has its share of trolls. I have personally seen fewer ugly posts recently, but any time I mention HN, folks reflect on the ugly, mean comments they’ve encountered on the site. Here’s an example of some people’s feelings.
  • I’ve had people ask me not to post their content without warning them. This is because of the kind of feedback they get from the site; they want to mentally prepare. That they’d even feel the need to do that is icky.

I think finding a community or three is a key part of growing as a developer.

While HN is not perfect nor it is as welcoming as other communities like the one around the Ruby language, the breadth and volume and diversity of it has been helpful to me.

So, I plan to keep collecting internet points for the coming years.

Community Devrel Tips | moore |

Thoughts on managing a devtools forum

I’m one of the team members tasked with managing the FusionAuth community forum, where folks using FusionAuth who don’t have a paid support plan can find help and answers.

Here’s some advice for running such a forum. (I wrote previously about why you should use a forum rather than Slack/Discord/live chat.)
  • First, consider why are you going to run a forum? Lots of great reasons: ease a support burden, help with SEO, foster community, get product feedback. Get clear on what you are trying to build before committing, because it is a commitment.
  • Choose forum software carefully. Migration will be a pain. Common options include nodebb (what we use), discourse, and vanilla forums.
  • Seed the forum. This means gathering up questions as you see them pop up in other venues (support tickets, GitHub issues, customer calls). I did that religiously for a few months. I learned a lot about the product and the forum posts meant that folks were helped even when it was new. I’d recommend posting the question and then responding in-thread with an answer.
  • Forums will bubble up commonly asked questions. This can tell you where your docs should be improved.
  • You must groom the forum. It won’t be set and forget. You have to pay attention to it, answer questions, respond to responses. A forum full of unanswered questions is worse than no forum at all. Trust me, developers will notice (we’ve had customers mention that they appreciated how active our forum was).
  • Because we sell support, we don’t answer questions immediately or have engineering staff answer them. There are also questions that we can’t answer such as architecture recommendations. Immediate responses and answers requiring context and research are reserved for paying customers. This hurts my heart some times, but we are open about it. May not be applicable to in all cases.
  • Don’t be afraid to ban users. We ban anyone who spams, no questions asked. Delete the content and ban the user. We luckily haven’t had any abuse issues beyond spam.
  • Have a code of conduct. I grabbed GitHub’s (you can see ours here, and here’s GitHub’s)  but have something. We didn’t in the early days, but it’s a good thing to have out of the gate.
  • Don’t expect a lot of community to grow out of it. At least, I haven’t had that experience, most people just want their questions answered. May be because I’m extremely part time on it and haven’t fostered it, though. Slack/discord is much more likely to build community in my experience. But know what your users want: Google or Facebook?
  • At a certain point, I had to enable a post queue, where a team member approves every new user. We were getting a lot of spam accounts and then they’d post gambling ads and then direct a ton of traffic (1000s of pageviews) to the ads. I don’t know what the spammer endgame was, but approving each new post has solved the issue. I’d definitely look for that feature.
In general I love forums, and so do devs, but they do take some work.
Devrel FusionAuth Tips Web Applications | moore |

How to be a good conference talk audience member

I recently attended a conference and was both a speaker and audience member. It was on the smaller side; there were probably a few hundred attendees and the audiences ranged from about twenty to hundreds of attendees for the keynotes.

After one of the talks, a speaker came up and said “you were such a good audience member, thank you!”. I said the same thing to one of the attendees of the talk I gave.

I wanted to share how you can be a good audience member at a conference talk. It’s important to note that this advice is for attending in-person talks where the speaker can see the audience. This is typically when there are up to one hundred people. I’ve spoken in front of 800 people and it’s a different experience. While some of these principles apply, in general individual behavior is less important as audience size grows.

And online talks are an entirely different experience for everyone, both audience and speaker! I don’t have enough experience to give any advice for that scenario.

First, though, why would you care to be a good member of an in-person audience? After all, you are providing your time and money to the conference and the presenter. Isn’t it the speaker’s job to entertain and educate you? Why would you expend any energy to help them do so?

First, I’m a big fan of being respectful of other human beings and helping them succeed. Public speaking is a common fear and being a good audience member can reassure the speaker and reduce that fear. It’s hard up there, whether it’s your first talk or your hundredth.

The second reason is that you can make a talk better for yourself. You can learn more and you can tune their presentation to your needs. They are an expert and you can take advantage of their expertise.

So, here are my tips on how to be a great audience member:

  • First, remember that you don’t owe the speaker your time, but you do owe them respect. If you aren’t interested in the talk, if it isn’t what you thought it would be, or if you have another commitment or pressing issue to address, leave the room. Don’t make a big show of it, but get up, walk quietly to the door, open it carefully, and depart.
  • Since you’ve decided to stay, pay attention. Silence your phone. Turn off your computer. If you want to take notes using your laptop, disable wifi so you won’t be distracted.
  • When you understand and agree with something, nod and smile. This feedback provides the speaker a signal that they are reaching you.
  • If you don’t understand, frown or make a questioning face. No need to harumph, but give the presenter feedback that the topic is confusing or that they haven’t made their point clearly.
  • If you have questions, ask them. Speakers should inform you if they want to be interrupted with questions during the talk up front, but if they haven’t, a polite hand raise should be acknowledged. If it isn’t, save your questions for the end.
  • When asking questions, realize you may not get a complete, satisfactory answer. If you don’t, I’d avoid a secondary question. Instead approach the speaker after for a more in-depth discussion.
  • If you didn’t like or understand the talk, give that feedback to the speaker afterwards. No need to be rude, but saying something like “I wish you’d given more background on <X>” or “It seemed like you skipped over the complexities with <Y>” will help the speaker improve their talk.
  • If you feel moved to do so, thank the speaker afterwards. This is not required but a talk is a lot of work and any feedback is usually welcomed.

Am I always a good audience member? Nope.

I get distracted sometimes.

But when I follow my suggestions above, I learn more from the expert on the stage.

Conferences Tips | moore |

Ask for no, don’t ask for yes

I think it is important to have a bias for action. Like anything else, this is something you can make a habit of. Moving forward allows you to make progress. I don’t know about you, but I’ve frozen up in the past not knowing what the right path was for me. Moving forward, even the smallest possible step, helped break that stasis.

One habit I like is to ask for no, not yes. Note that this is based on my experience at small companies (< 200 employees) where a lot of my experience has been. I’m not sure how it’d work in a big company, non-profit, or government.

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

Let’s see how this works.

Suppose I want to set up a new GitHub action that I feel will really improve the quality of our software. This isn’t whimsy, I’ve done some research and tested it locally. I may have even asked a former colleague how they used this GitHub action.

But I’m not quite sure. I want to let my boss know that I’ll be modifying the repository.

I could say “hey, boss, can we install action X? It’ll help with the XYZ problems we’ve been having.”

If you have a busy boss (and most people do), this is going to require a bit of work on their part to say “yes”.

They’ll want to review the XYZ problem, think about how X will solve it and maybe do some thinking or prioritization about how this fits in with other work. Or maybe they’ll want you to share what you know. It may fall off their plate. You will probably have to remind them a few times to get around to saying “yes”. It might be a more pressing issue for you

Now, let’s take the alternative approach.”Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.”

Do you see the change in tone?

You are saying (without being explicit) that you “got it” and are going to handle this issue. The boss can still weigh in if they want to, but they don’t have to. If they forget about it or other issues pop up, you still proceed. This lets you keep moving forward and solving problems while keeping the boss informed and allowing them to add their two cents if it is important enough.

You can also use this approach with a group of people.

By the way, the deadline is critical too. Which would you respond to more quickly, if it was Jan 15, all other things being equal and assuming a response was needed?

  • “I’m going to do task X.”
  • “I’m going to do task X on Jan 17.”
  • “I’m going to do task X on Feb 15.”

I would respond to the second one, which has a deadline in the near future. I think that is the way most folks work.

Again, pursue this approach for problems you feel are in the scope of your role but that you want to inform the boss about. It’s great when you want to offer a chance for feedback, but you are confident enough in the course of action that you don’t need feedback.

Lifehack Tips | moore |