Skip to content

Latest commit

 

History

History
44 lines (33 loc) · 2.42 KB

simplicity.md

File metadata and controls

44 lines (33 loc) · 2.42 KB
Raw

<-- Home

To Code Or Not To Code, That Is The Question

By all accounts from modern technical interview observations, the business wants you to be a computer. They ask you the same questions you can describe to a computer at a much higher level. They expect you to know multiple algorithms to solve the task and which one is the most efficient.

But unlike a computer, you're supposed to talk back to them and ask questions. "Why are we wasting time with this exercise?" is unfortunately not a valid line of inquiry, but it is and should be a valid line of inquiry in your actual day-to-day work. We are not computers, and we can provide the most value to the business when we stop acting like ones.

A Few Key Questions

In our quest to think simply and provide the greatest business value, we need to orient around a few key questions in our thought processes:

  1. Is the next link ready to accept my work? Every task can be thought of as a series of chains that lead toward a successful code deployment. Each task will vary in the number of links needed to deploy the code, and we should make sure to not work on links that have broken parts ahead of our work.

  2. What is the minimum amount of work needed to gain feedback? We only need to write enough code to gain insightful feedback. For example, if you begin a new project, you don't need to get all the CI/CD work done before you try to deploy the app on a hosting provider. Instead, put up a " Hello World" app and make sure it runs where you need it to most.

  3. Can this task be completed in one or two days? Commonly, issues are born out of jotted down notes and this can lead to a very complex task ending up as one issue. Ask yourself: "Can I complete this task in a couple of days?" If the answer is no, then you need to break the issue down into multiple steps or make it an Issue Epic. If you are at the end of day one and know you won't finish on day two, then commit what you can and make follow-up issues with better scopes.

With answers those three questions you should be working efficiently on only the amount of work that can be completed by one person in a reasonable enough timeframe for insightful feedback.

Inspirations