Greg Answer

The Importance Of Side Projects

2023-10-15T12:05:00+00:00

I don’t know where to start this post. I just know that side projects are really important. Underrated even. I do them whenever I’m curious or when I want to strengthen my knowledge in one area. I’ve taken them for granted.

Many engineers I’ve spoken with don’t really invest in side projects. Whenever I show them something cool that I did, they ask “Where did you learn that?” Side projects.

If you’re hoping to learn everything you need on the job, keep hoping. Companies need you to get things done, not to spend time learning. Learning is definitely a bonus. If you’re lucky enough to work at a company that emphasizes learning, congratulations. For everyone else, you need side projects.

Side projects range from courses and books to full applications that you may intend to offer as a service. Whether your goal is to make money or just to learn, your side project will stretch you in ways you never thought possible.

Advantages

Below I will list some of the many advantages of side projects.

Learning and relearning. There are so many engineering principles that we don’t practice regularly. A recent side project I worked on reminded me of the importance of specifications and ensuring the components you select meet the minimum criteria.
Practice. Struggling to learn a tool or technique? Build a side project that forces you to practice this repeatedly.
Sharing and teaching others. If someone asks you, “How do I work with XYZ?” it be great to reply, “Checkout this side projects I have on GitHub.”
Getting better at your job. As I mentioned previously, many of the skills I have are from practicing on side projects, where I have time and the outcome doesn’t really matter.
Provide insights and tools for your job. At every company I’ve worked at, I’ve added at least one tool that improves the workflow of many people. These all started as side projects I was curious about.
Satisfaction of completing something, even if no one uses it. As engineers, we should strive to build things which give us a sense of accomplishment, even if that only happens outside of work hours.
Faster feedback. Lessons that take six months to learn on the job can take six days to learn in a side project.

Examples

Now that you know some of the advantages, you might be thinking, “How do I get started?” You probably don’t want to build another boring “TODO App” right? Here’s a short list of meaningful side projects.

Rewrite exiting internal code. Take a module or project from your company and try to rewrite it in your own way. Of course, be careful not to leak intellectual property.
Rewrite exiting external code. System Design courses and books often ask you design Rate Limiters, Instant Messaging, Video Streaming, etc. You might focus on the high level design or just a single module.
Build a new tool. Tired of Jira admin for your Merge Requests? Build a workflow CLI and share it with your friends.
Build a new app. One the first apps I built and rebuilt many times is Qwiz Notes, a social network for students to study. This is long before the AI explosion but this app taught me how to build whole projects by myself.

Conclusion

These are just some of the examples and advantages of side projects. I understand that this may seem overwhelming but you don’t need more than 10 hours a week to get the benefits. You just have to be disciplined and remember why you’re doing this. If you don’t have discipline or a goal, then none of the above matters.

Remember to keep it fun and engaging. Feed your inner child with playfulness and curiosity. These 2 things will take you further than you can imagine.

Over Abstracting

2023-09-30T12:05:00+00:00

I’m tired of over abstracting… and I’m over it. There. That’s the blog post.

I can’t tell you how many times I’ve written a class that has like 20 functions that just return 1 line. All to be used by the 3 or less public functions. Why do I do this? Is it really “clean code”?

I spend a decent amount of time rewriting code to learn from it. Sometimes I rewrite the same class or even a small sub system. Sometimes I rewrite it once or even 5 times.

One of my recent rewrites is an AWS lambda function. I previously wrote a version of it that has 10 functions in 3 files, not to mention the utility functions that it also calls.

I tried rewriting it in one big file. I found it “overwhelming” to approach at first. Once I realized that everything this lambda function does is in this one file I felt a bit of relief. No more jumping around between files!

In my defense, when I first wrote this lambda function, I was trying to keep it abstract because there were 3 other lambda functions that would share some of the same code. It turns out those functions maybe shared 10% of the code that was abstracted. Not worth the headache of jumping between files. Lesson learned.

So I left the one big file alone for a few days and recently came back to it. Why are there so many functions?! Before there was 10 functions in 3 files. Now there’s over 20 in one file! About 5 of them were some of the utility functions from the previous version.

I did my best to make each function read from top to bottom, as mentioned in Chapter 5 of Uncle Bob’s Clean Code book, but it’s still too much jumping around. How is this any better?

Why do I have so many functions? Because I want named behaviour. Sometimes I read a few lines of code and have to think for 30 seconds in order to grasp the high level concept. This thinking is reduced to 1 second with a well named function that groups these few lines of code. But the jumping back and forth for a simple piece of code that is not being reused is not worth it.

So I rewrote the lambda function today. I’ve lost count how many times I’ve rewritten it. Like a painter, I’ll keep repainting the same bowl of fruit until I’ve learned all I can from it.

I have not completed the functionality but so far there’s only 3 functions. From what I can see in the previous rewrite, I’ll only need about 5 more functions. 8 functions in 1 file. Depending on who you are, this sounds like a dream or a nightmare.

How will I compensate for the “what the hell is going on here?” affect? Code comments. Short descriptive comments that explain a grouping of 5 or so lines and prevent me from having to jump to the another part of the file or worse, another file.

I’ve long believed that code comments are bad. They’re a sign that you did not explain the code well with good variable names and extracted functions. Sometimes code is too hard to explain in a function name. Sometimes extracting a private function to the bottom of a 200 line file is a bridge too far. Then you’ll tell me to extract the 200 line file into two 100 line files. As Ryan Reynolds said in Harold & Kumar Go to White Castle, “But why?”

Clean code is more of an art form and a balancing act. What’s clean to one individual or team is a dirty dumpster to another. One thing that doing a lot of Leetcode questions has really taught me is “Make it work, then make it right”.

I’ve solved and re-solved hundreds of Leetcode questions with the average function length of 25 lines. At most I’ve used 4 functions for Union Find solutions just because functions named union, find, and are_connected just read a bit better. Otherwise it’s just the problem’s function and 1 or 2 helper functions.

Since “right” is really subjective, I rather “clean” the code days or weeks later once we actually have a need to clean it. Cleaning it too soon can lead to code that’s actually messier for your future self.

The Importance Of Examples

2023-09-24T12:05:00+00:00

I was working on ticket recently with a simple-looking front end change. There was a screenshot of the expected output. Modifying React code is rarely simple but that’s topic for another time. I spent about 1 day on this.

I showed it to my co-worker and they told me I was missing a subtle change. I stared at the screenshot very carefully, scratched my head for bit, and then I saw what was different. I had to rewrite the code a bit to get that change but that only took half day. And then I was done. Or was I…

Although we write unit and integration tests, nothing beats opening up an app and manually clicking around. Do I understand this feature? Is it working as expected? Are there any unexpected bugs or quirky interactions? These are best answered by following a test plan that forces you to manually walk through the app and think like a user.

I asked the team if there were some QA steps since this area of the code was recently changed. They said no. No biggie, the QA engineer will write some steps. Nope! He was busy.

Alright, time to roll up my sleeves and write some QA steps. I’ve done this many times, but not recently because usually the QA engineer or the whole team will write the steps together.

The next few days were interesting to say the least.

QA steps

There’s an edit page for a business critical model. There’s 2 “categories” for the type of model. I put that in quotes because there’s really there’s 6 types but they can be simplified into 2 categories that have different behaviours.

Software engineers should be aware of the acronym CRUD, which stands for Create, Read, Update, Delete, which is the basis of all actions you would do in an application.

Also, there’s a feature flag that adds new functionality to one of the “categories”.

So for those of you counting, technically there’s 6 types * 4 CRUD * 2 flag states = 48 different tests cases that could be executed manually to confirm that all new and existing functionality is working as expected. Ouch!

Well maybe if I group them as the 2 categories I can reduce this 16 test cases instead of 48.

In order to update or delete something in the UI, you generally have to read it first. This reduced the test cases down to 12.

I wrote out the test cases and started testing the code. Time to watch the bugs fly in!

Remember the part about React not always being simple? I had inputs that were overriding data on the back end. I had inputs that were blank even when the value was present on the back end. I even had values that I “deleted” on the front end, partially deleted on the back end, and fully showed up on the front end like nothing happened. Some of these were from the new code, others from existing code. Fun times!

While poking around on the front end I realized that you could actually add/update/delete multiple values at the same time. Oh no! Do I have to add more tests now? Nope! I just updated the tests to say something like “I add 1 value, I see the results, I add 2 values, I see the result”. I repeated this for the update and delete test cases. The back end already tests this in subtle way, but it’s good to be explicit with End-to-End testing.

Throughout the week, each day felt like 2 steps forward, 1 step backward. The first few days felt like a regression. I had this “feature complete” but was unable to make my own test cases pass! Everyday at standup I felt like a bum but my team was supportive. Each day I told them what test cases I wrote, what bugs I found, and they were generally impressed with the depth of my testing strategy. As a company, we’re improving out testing strategy and we said that we would reuse these tests for the rest of the project and for regression testing the part of the app in general. This is why I put in the extra effort. It will not be for waste.

Takeaways

My main takeaway is that I wish I had found or written the QA steps before I began working on the ticket. Even if the QA steps already existed, I definitely gained a deeper understanding and appreciate of the feature by writing the QA steps my self. These should come first to ensure you understand what’s expected of the feature.

My secondary takeaway is the value of my Personal Problem Solving Template. Though it keeps evolving slightly, this is the foundation of software development for me. In this situation, even though some high level examples were given to me on the ticket, taking the time to explore deeper will ensure that there are little or no unexpected behaviour, as I had encountered.

How I Read Books

2023-09-17T12:05:00+00:00

I read a lot of books in 2019 and then I fell off the wagon. This year I got back into reading and I realize how much I missed it. There’s some books that I read a while back that I forgot. So I decided to re-read some of them.

About 5 of the books I read this year are books I’ve read in the past. Good books. Great books! Why don’t I remember them?

After reading 2 of them I said to myself, “You can’t let this happen again. You need a better system.”

This required some deep thinking and experimenting…

I love reading on my Kindle e-reader. It’s a distraction-free device that is comfortable to hold. I can sit, lie down, stand, be in the car, on the bus… anywhere. I love Kindle! But I don’t take great notes on Kindle. This is not a promotional post. Use whatever device you prefer.

Placing notes in an online note taking app is best for long-term searchable notes, but not great for learning. And we all know how distracted we get while using a internet connected device like a computer, tablet, or phone.

Handwritten notes are the best overall. They engage your brain in a way that highlighting or typing can never replace. There’s plenty of studies on this. But while I’m reading I don’t want to have an extra book on the side. Also, handwritten notes are not searchable.

So I want to read on a Kindle, handwrite my notes, and make them digital for long-term storage and retrieval. Sounds like a lot.

I believe I have a pretty good solution right now and I can walk you through the phases of development for people with different budgets and preferences.

Phase 1: Highlighting

Those of you have an e-reader like a Kindle know how easy it is to highlight a passage of text. You can highlight a word or even a few pages. These highlights are accessible on the Kindle e-reader and on the Kindle app available on computer, tablet, and phone.

Advantage: I don’t need an additional device or notebook to take notes.

Disadvantage: Even if you read your highlights later, your brain was never really engaged with the material. Plus you can easily highlight too much and have no way of actively recalling the core principles of the book.

Phase 2: Typing up the highlights

Since the highlights weren’t really sticking with me, I decided to type up notes again. I would read a book and highlight as I please. Once complete, I would review the highlights in the Kindle app and then type up my own words.

Advantage: Still don’t need an additional device for notes. I also get a condensed long-term version that I can review.

Disadvantage: My brain is still not making deep connections with the material.

Phase 3: Handwriting then typing up the highlights

Comprehension and recall are most important when learning, thus I spent some time only reading if I had a notebook nearby. I’d still highlight notes, but anything I felt truly inspired by, I would spend some time to write on paper.

Advantage: Deeper understanding and appreciation of the text. Writing slower forces you to write more efficiently, forcing you to think and summarize better.

Disadvantage: I need an extra device or notebook when I’m reading. This means I can only really read at a desk, limiting when and where I would consider reading.

Phase 4: The Kindle Scribe

The Kindle Scribe… no affiliate link… wow! Finally a device where I can have it all.

I can read with the Kindle experience, highlight with the Kindle experience, and now you can handwrite little sticky notes right on the book!

Since the Kindle Scribe has notebooks by default, now I copy and paste my handwritten sticky notes into a notebook. I try to make a one page summary for each book that I can review as often as needed.

Advantage: No additional device for notes. All the advantages of handwriting. I can still type a long-term searchable version of my handwritten summary.

Disadvantage: Price? But if reading is an important part of your career and even your life, it may be worth the investment.

Conclusion

Regardless of whether you prefer physical books or e-readers, I believe most humans need to handwrite a summarized version of the book in order to commit the key concepts to long-term memory. For me it’s important to find the right tools that make this process enjoyable.

Before the Kindle Scribe, it was all about perfectly selected pens and notebooks. I could go back to these, as they are still wonderful tools. I have been using my Kindle Scribe daily for a few months now and I will continue to do so.

This is not a promotion for the Kindle Scribe. Just a promotion for finding tools that help you read and learn in a way that is most suitable for you.

Dependency Dilemma

2023-09-10T12:05:00+00:00

I was working on a microservice API that is used as mock integration for a third party API. We asked the vendor to make one for us but it’s not a priority on their roadmap so I built one for us. This API is used every day for testing and rarely has issues.

I needed to add a small change that should take 20 minutes to write, test, and deploy. I only modify this app once every few months for the past year and each time has been pretty easy.

I made the change locally. I tried to run the code and I got an error. The first of many.

The first error was about the version of the Serverless Framework I was using. The project was using v2 and I had reformatted my laptop a few months ago (another story) and only have v3 locally. I quickly checked the docs and there’s only some small changes to the config file and everything else should just work. Better change it now than later.

The second error was about the version of node I was using. The project was using v12 (ouch!) and I only have v18 locally. Remember that reformat? I don’t want to download an old, security nightmare that nobody wants to maintain. No problem. Update Node.

AWS also no longer supports anything less than v16. I had to update this in Serverless config file as well. Not too bad.

The third error was about the incompatibility of a dev package and the new version of Node. Uh oh! Wait… This package is no longer being used in this project. Delete it!

The fourth error was about the local AWS Dynamo DB dev package I was using. This package allows you to run the Serverless code locally by pointing to a local instance of Dynamo DB. An hour of research later, this package is no longer being maintained and any forks of it are also questionable. This mean no more local development for this project. 😞

Oh well. I can always just push the code to a “dev” server to not interfere with the actual APIs that depend on this mock service.

The fifth error was one of my favorite random Cloud Formation errors. Once or twice before, during a deployment, I’ve seen this error. Thankfully I was only deploying to the “dev” server. It basically says that I have to go into the AWS Console and manually delete some services that may have been corrupted during the attempted deploy. At least I’m vaguely familiar with this one and now moving in the right direction. Delete all the related resources and try again.

The sixth error… yes, there was a sixth error. The sixth error was something like, “Undefined AWS package”. Another hour of research to confirm that I have to update the AWS SDK from the v2 to v3. I’m not sure when this was deprecated but again, I’d rather update it now and hopefully not deal with it for a while. There’s an AWS “update script” that is supposed to update the code to use the v3 syntax. I ran the script and verified that my code looked the same as the documentation examples.

The seventh error… how much longer is this going to take?! The seventh error was that Typescript was not happy with the return value of some of my functions. I double checked the AWS update script and docs and my code looked like the examples they gave. The Typescript error was not too helpful and nor was Google. I knew I either had to change the expected return value or the actual return value.

I went for a walk around the house.

I came back and said the easiest thing to do is remove the promise() function that was being returned from the 7 functions that called the AWS SDK and see if the new error is more helpful. Now only 6 Typescript errors. Ok. Let’s remove them all. Now no Typescript errors. Try to deploy to “dev” server now…

The eighth error… nah just kidding! Finally. Back to baseline. And I still haven’t implemented the small change yet!

After a few days, I had to take step back and think about what I would do differently:

Avoid local dev for Serverless projects. I was a pain to setup, a breeze to use, then a pain to update. That evaluates to a pain sandwich I’d rather not eat again. If the tech was more stable and better maintained it might be a different story.
Avoid Typescript for small projects/teams. Another pain sandwich. Yes it did help me identify the wrong return type but initial setup and making small changes can be quite time consuming. I think It makes sense for mission critical apps and large teams. Maybe even mission critical functions in an app but not necessarily the whole thing.
Avoid Serverless Framework for small projects. This one is a bit tricky because there are some nice features to it. This project has 4 lambda functions, 2 SQS queues (which are probably unnecessary), and 1 API gateway. For this project, the framework is just another layer to maintain and configuring this app for 2 “environments” is not that much harder using AWS Console.

I believe 5 of these 7 errors would have been eliminated if I avoided the 3 things in the list above. I learned a lot using these tools and I have no regrets but I would not use them again for small projects.

Try A/B testing your dependencies. Try working without one or more for a few weeks. If you still need them, document why with a few examples. You can add this to the project README for future developers to to review.

I’m very cautious with production dependencies. I check for longevity, activity, popularity, and maintenance of packages before pulling them into my personal or professional projects.

I have a few stories and there are many other stories of popular package that just stopped working one day. Just google “colors.js and faker.js”.

I once worked with a senior engineer who avoided dependencies as much as possible. Forget about production dependencies. Every time I wanted to add a dev dependency he would ask why I need it. I’d explain it to him and he’d say, “You can just write that yourself.” I thought he was crazy and paranoid. Now I am him.

Software Engineering Seniority

2023-05-30T12:05:00+00:00

Every engineer and every company has there own definitions of seniority. They have rubrics, require certain hard skills, and even behavioural aspects they need to see before they consider someone “senior”.

I’ve been thinking about this for the past few months and I’ve come up with a simpler set of attributes that I need to see in good engineers. These are Problem Solving, Communication, and Speed. I believe these attributes should be learned in order.

You will continue to enhance them over your career but you should aim to get each to an intermediate level before moving on to the next attributes. I’d much rather work with a person who can solve problems independently and slow than with someone who can only move fast and needs to be told exactly what to do. That’s what machines are for.

Below I break these skills down by engineer level, just to give you a better feel for what I would expect for each level.

Junior

Focus on Problem Solving. Deeply focus on this. Take extra time if you need to. This is the core skill of any engineer (software, hardware, civil, etc.). Learn how to take an idea/request and break it down into smaller more manageable problems. Come up with multiple solutions and discuss tradeoffs.

You can enhance this skill by:

Reading books such as Think Like a Programmer by V. Anton Spraul
Finding courses that focus on practice with real-world problems
Building side projects
Practicing Data & Structures and Algorithms on sites like Leetcode
Taking on more challenging projects at work when you’re ready

Intermediate

Learn internal/external communication. It is not enough to solve problems. You have to learn how to find out what problems to solve. You also need to follow up to verify that your solution solved the problem. Get comfortable talking or texting with:

Anyone on your team
Anyone on other teams
Stakeholders
Customers

The key here is to focus on positive interactions that make people want to continue to work with you. Efficiently communicating the right thing, to the right people, at the right time shows your level of responsibility (ownership) and builds people’s trust in you.

You can enhance this skill by:

Reading books such as How to Win Friends and Influence People by Dale Carnegie
Giving demonstrations at work
Leading meetings at work
Writing blog posts
Doing Tech Talks at conferences

Senior

Learn speed. Not typing speed. Not talking speed. Outcome speed. We develop software so that people and businesses can achieve certain outcomes. At more senior levels, we aim to reduce the time it takes to achieve the same outcomes. This can reduce company operating expenses, increase the return on investment, and decrease the time to market.

You can enhance this skill by:

Reading books such as Dive Into Design Patterns or Dive Into Refactoring by Alexander Shvets
Focusing on prototypes and feedback early in the process
Using the Pomodoro technique to limit time waste
Asking/observing how other do these things fast

Senior Plus

Learn planning and discovery. This is what makes or breaks the business. The better you get a breaking down work and proactively solving problems, the better chance that the business will keep customers happy and remain profitable. Time, money, and labor are limited resources that must be carefully managed.

You can enhance this skill by:

Reading books such as Getting Real by 37 Signals or The Nature of Software Development by Ron Jefferies
Build a relationship with your manager and product manager
Ask to help plan larger projects or take on small ones by yourself
Planning and developing side projects
Read/watch how other small and large businesses succeed

In some companies you may need to show these skills before promotion. Example: improve external communication before being considered senior.

In my opinion, everything else is a subset of these that can be learned:

On the job
Through reading
From Mentors
By doing side projects

Some examples skills:

Data Structures and Algorithms
System Design
DevOps
Presentations
Negotiations
Agile practices

Based on your job description, take your time to be familiar, not necessarily proficient, before applying.

The main challenge with all of this is How do you know when to move on to the next attribute? Talk to your manager and peers. Tell them you’re focused on the Pareto principle and you will continue to improve on these attributes throughout your career.

I didn’t mention quality anywhere. This is on purpose. You should build quality into each of these attributes. The question of how much quality is dependent on your time/money budget, which is a discussion for another time.

Maximize Effeciency With Pomodoro Mastery

2023-04-02T12:05:00+00:00

Time management is a crucial skill for success in any field, and the Pomodoro technique has become a popular method for improving productivity and reducing distractions.

What are Pomodoros

The technique involves breaking work into 25-minute intervals, called Pomodoros, followed by a 5-minute break. After completing four Pomodoros (approximately 2 hours of focused work), take a longer break of 15-30 minutes. This extended break helps further rejuvenate your mind and ensures you can maintain productivity throughout the day.

During the Pomodoro session, focus entirely on the chosen task. Eliminate distractions, such as email, social media, or unrelated tasks, and concentrate solely on the work at hand. If you’re interrupted or realize you need to do something unrelated, write it down and come back to it later.

How I use them

Setup

Instead of a 25 minute work session with a 5 minute break, I prefer to work for longer with 12 minute “reminders” in between.

I have a digital kitchen timer on my desk that remembers the last timer interval I set. I quickly double tap the start button and it starts counting down. When the timer is done, I set it to flash instead of making a noise. I do not want a significant disturbance, just a light nudge.

Before I begin a task, I usually set a time budget for it. However many Pomodoros I think it will take, I usually double it to get a range estimate. Examples:

I want to read an article in 1 Pomodoro, so I’ll give myself 1-2 Pomodoros of time to finish it.
I have a work task to complete that I estimate can be done in 3 Pomodoros. I’ll give myself 3-6 Pomodoros to complete it.

Doubling the estimate is important becuase humans suck at estimates and random things often happen that cause tasks to take longer.

After each Pomodoro

Every 12 minutes, the kitchen timer starts flashing. This is my wake up call. I tap the stop button and take a couple seconds to check if I’m making progress as expected, based on the time estimate and task complexity.

This is also a good time to check if I need a break. I usually physically take a break every hour. I’ll take more frequent breaks if my energy/mood is low or if the task is too challenging/boring.

If I don’t need a break and I’m not making progress at the pace I expected, I stop and reassess my strategy and time estimate. I try to change my strategy to gain time (brute force solutions, 80/20 solutions, skim the article faster, etc.). I also accept that I may have underestimated the task and need to add additional Pomodoros next time I do a similar task.

After each Pomodoro, I check if I’m X percent (or fraction) complete. Using the examples above:

After the first Pomodoro of reading I hope to be done or at least half done
After each Pomodoro of the task, I quickly check, “Do I feel I am 1/6 complete? 2/6 complete?…” etc.

When I take a physical break I usually go for a walk around the house, grab a snack, and/or do some yoga. Sitting or standing in one place for too long is no good for your health. Getting up to get blood flowing will help you with your tasks so it’s a win-win.

Helps avoid rabbit holes

The reason for doing Pomodoros like this is that we all get stuck in rabbit holes. Pomodoros help you stay on track. These check-ins may seem like extra work, but I can’t tell you the amount of times I spent hours going down interesting rabbit holes while my task remains incomplete.

The power of the Pomodoro comes from the times when I catch myself going down a rabbit hole. Example would be I’m trying to work on a task, my timer goes off, I look at what I was last doing, and I see that I was investigating something interesting yet tangentially related to what I’m working on. This is a good time to write this idea down for later exploration. Thankfully I only wasted 12 minutes, rather than several hours.

Slack, email, and social media are special forms of distractions. Some are necessary for the job, while others are not.

If you need to stay connected on other tasks such as Slack and emails, after a Pomodoro is a good time for this. Rather than having constant notifications that take you out of flow state, you can give yourself 5 minutes to respond to the most urgent messages in between your Pomodoros. All other non-urgent messages can be batch processed during designated times. I’ve been doing this for almost a year and no one has complained that I’m unresponsive.

Some Notes

This is how I’ve been using Pomodoros for almost a year now. Your mileage may vary. Some things to consider:

Your Pomodoro duration is up to you. The standard is 25 minutes but depending on your personality and the task you may find it too long or too short. Experiment until you’re comfortable.
You don’t have to Pomodoro every task. For writing this blog post I estimated 2-4 Pomodoros. It took 4 Pomodoros. I wanted to focus on getting all the high level details written out quickly. When I was editing, I did not set any timer. At this point I care more about quality than speed.
Take breaks as needed. The standard is every 25 minutes you take a 5 minute break. Depending on the task, this might break your flow. Currently I can go 4-6 Pomodoros (48-72 minutes) continuously on most tasks, I can do 2 hours if I’m in a flow state. Writing and editing this blog post took about 2 hours with only 1 bio break. I stood for the first hour, then sat for the second. Keep a snack and water nearby.
When in flow state, you can disregard the timer or just do a quick “Am I on task?” mental check-in each time you reset the timer. At the end of each task, you should reflect on how the task went and how much time was spent. You only need to change strategy if you feel you were inefficient (spent too much time or worked on the wrong thing).
Reflect on what works and what doesn’t. After each task or after every few tasks ask yourself questions like:
- Was I focused enough?
- Was I fast enough?
- Do I need to get better at estimating?
- Do I need to make smaller task chunks to improve speed or quality?
- Do I need to put my phone in a different room? Do I need some “distraction free” browser plugins that use a timer?

I was skeptical when I first started using Pomodoros a year ago. It just wasn’t working for me. I tried 25, 45, and 90 minute Pomodoros and the 12 minute version has been working best for me for the past few weeks. I encourage you to continue experimenting to find the setup that works best for you.

Jira Ticket Template

2023-03-28T21:05:00+00:00

I’ve been writing a lot of Jira tickets lately. About 10 in the past week. I’ve refined my personal Jira ticket template over the course of the last few months. Here are the sections I add and why I add them.

Title

Most issue tracking software has a title or summary field that is required.
The title should be short and descriptive.
- This makes them easy to find in different views like board view.
- This makes it easier to reference while talking/texting.
Preferably starts with a verb.
Examples:
- Allow admin to set email notification frequency for subscription X
- Update endpoint X to handle bulk data
- Add alert when orders exceed 10K
- Document instructions for manual process X

Body

The body should be short and skim-able. Respect that the reader is a busy stakeholder who needs to quickly find out why this ticket is necessary. I borrowed from the Problem Statement template and customized it based on my uses.

I use H2 headings so that I can jump to the appropriate sections as needed. It contains the following H2 headings (in order): Objective, Consequences, Workaround, Proposal.

Objective

I reuse the title and add “so that…” along with the benefits.
This is similar to the User Story format of “As a [PERSONA] I can [ACTION] so that [RESULT]”
Using the title examples above, the objective might look like:
- Allow admin to set email notification frequency for subscription X so that we can increase customer retention
- Update endpoint X to handle bulk data so that we can reduce server costs
- Add alert when orders exceed 10K so that admins can notify our vendors of incoming large orders
- Document instructions for manual process X so that on-call teams can run this process
If necessary, you could try some date specific Objectives. Examples:
- Integrate with API X by June 5th so that we can avoid the service fee increase of API Y on June 6th
- Complete feature X by August 12th so that we can secure the contract with client Y
- Create video describing feature X by March 27th so that we can present it at the XYZ conference on March 28th
Occasionally I add specific “Key Results” as additional bullet points. Examples:
- Reduce CPU usage by 10%
- Reduce Cost of Goods Sold (COGS) by $1.20 per order
- Increase customer retention by 15% throughout the third quarter

Consequences

The benefits should be clearly stated in the Objective section, but we also need to know what happens if we don’t do this ticket.
This helps us prioritize against other competing tickets.
If the consequences are low or unknown, I usually reduce the priority of the ticket (i.e: from a P3 to a P4)
Examples:
1. Users may get frustrated and abandon their cart
2. Server may become overloaded and data processing may fail
3. Our Cost of Goods Sold (COGS) will be $3 higher than expected

Workaround

This section is optional. If there is no workaround, I do not include it.
If there are workarounds, I list them here and I usually reduce the priority of the ticket (i.e: from a P2 to a P3).
The workarounds aren’t perfect. They ofter a temporary solution until this better solution can be implemented.
Examples:
- User can follow the manual process in document X
- Engineer can manually run code on the server
- Hire part time staff to help deal with the influx of orders

Proposal

Briefly describe your proposed solution to achieve the objective.
Use short bullet points. Skim-able is key.
- I can’t stress this enough. Most engineers don’t read the whole thing anyway.
Break them up into sections as needed.
- For example, I may have a bullet point titled “Frontend” with some sub points, and another bullet point titled “Backend”.
Be as prescriptive or as generic as you prefer.
- I tend to be prescriptive when I already know the solution or this has a tight timeline
If it’s a feature ticket, this is where I’ll add a short User Story in a code block using the Gherkin syntax.
Include code examples/prototypes but tuck them in an “expand” section so that the body of the Jira ticket is still skim-able.
I use “expand” sections for any part of the body that gets too long. Sometimes this is a sign that I should move this info to a separate document. The ticket is about getting things done, not telling a long winded story.

I kee these four H2 headings saved in Notion with one bullet point each. Whenever I need to write a new ticket, I just copy and paste it and start filling in the bullet points. With a good high level understanding of what needs to be done, I usually write a descriptive Jira ticket in under 15 minutes.

When I come back to the ticket later, I can quickly see the info I need without too much reading.

With Jira having so many fields that only a handful of people use, I find a simple Title and Body is sufficient for me to understand the task at hand. Other than the Priority, Sprint, and Epic fields, I hardly pay attention to anything else added to a ticket.

This template I find easiest to read and write. I can use it in any ticket tracking platform. This is just my preference. Maybe your team has one template for all issues. Maybe everyone writes however they feel that day. Do whatever works best for you and your team.

Web Weekly: Vol. 5

2023-03-21T21:05:00+00:00

I skimmed through dozens of newsletters this week. Here’s some interesting articles I found.

NOTE: Just because you read my summary doesn’t mean you understand the full point of original author. I recommend you read the full article if it’s for a topic that you feel is impactful to you.

Atomic Habits Visualized (Twitter thread)

Atomic Habits by James Clear is a great book that talks about how to make good habits so that you can achieve your goals
Each completion of a good habit is a “vote” for the person you want to become
The best work comes from focusing on quantity
Though I have not finished the book, the visuals in this Twitter thread are pretty good

A very nerdy perspective on naming things in programming (16 mins read)

My takeaway: Code should read like English (as much as possible, language dependent)
I skimmed through it but I will also read it slowly because this is important for long term code readability

Data centers at public pools keep swimmers warm (1 min read)

A tech firm is setting up its small data centers at public pools across the UK
Data centers need to cool down, pools need to heat up
The generated heat from the servers heats up the pool at a lower cost
This is a great example of what I like to call “Feed 2 birds, with 1 worm”
I hope no one has to open up the server to chain a hard drive anytime soon!

Advanced interview questions for a Ruby developer

Here’s a short quiz of advanced Ruby topics
I got about 9 out of 14 correct. Some questions are a bit more open ended and my answer was different.
I ran into Ruby super( ) again!
I learned a bit about garbage collection in Ruby

Mini Robot Enters Blood Vessels, Completes Surgery (1 min read)

A team of engineers in South Korea created robotically assisted magnetic navigation system for endovascular intervention (I-RAMAN)
A magnetic robot can use a 3D map of the patient’s blood vessels to navigate autonomously and perform treatments
I think this is really cool and I love to see technology like this saving lives

Prioritizing Tasks: ROI Over Everything

2023-03-15T21:05:00+00:00

On Sunday I was working on my blog. I wanted to add some Web Weekly content. I was looking at the existing 3 Web Weekly posts and I thought it was time to move them to their own collection.

I’m using Jekyll to load my site so I’m kinda stuck with how this needs to be implemented. Though this may seem like a limitation, hopefully in the long run it will force me to focus on what’s important. The details of how this works are not relevant to this post.

I believed this would take me about an hour and then I’d have my Web Weekly collection. And then I got stuck.

I couldn’t get the collection to be part of my feed.xml file. This file contains my blog post feed, which is used by MailChimp for email distribution. But I couldn’t merge in the Web Weekly collection.

At first I thought maybe I can join the feeds together on MailChimp. Nope. No easy way to do that. I also don’t want to pay extra for this or have any additional MailChimp administration.

Next I thought maybe I could configure the jekyll-feed plugin somehow. Back and forth with ChatGPT. Back and forth with Google search. Still no way to merge the feeds.

Then I thought maybe I could write the code for the feed.xml file. But this was going to take a bit of research based on the way my Jekyll site is setup.

Times up!

An hour goes by fast. What have I accomplished? Nothing. I thought to myself, “Maybe I should try a little bit more.” Then I asked myself, “What are the consequences of not doing this?” Nothing. It might be better if I do it, but it certainly won’t be worse. So why bother?

I wish I asked myself this question before I started, “What are the consequences of not doing this?” This should be what drives my personal and professional priorities everyday.

With negligible consequence, this is a task that should be deferred or delegated. I have no one to delegate this to at the moment. There is no strong positive outcome for this task right now. So it will be deleted.

The workaround right now is to use the tags. This is perfectly fine.

If this becomes a pain point for readers, I will assess the situation in that moment. Not before. Even though I was hoping to make things ~~easier~~ prettier for myself, I just wasted time for a small potential return on investments (ROI). I need to focus on larger ROIs.

Greg Answer

The Importance Of Side Projects

Advantages

Examples

Conclusion

Over Abstracting

The Importance Of Examples

QA steps

Takeaways

How I Read Books

Phase 1: Highlighting

Phase 2: Typing up the highlights

Phase 3: Handwriting then typing up the highlights

Phase 4: The Kindle Scribe

Conclusion

Dependency Dilemma

Software Engineering Seniority

Junior

Intermediate

Senior

Senior Plus

Maximize Effeciency With Pomodoro Mastery

What are Pomodoros

How I use them

Setup

After each Pomodoro

Helps avoid rabbit holes

Helps avoid social distractions

Some Notes

Jira Ticket Template

Title

Body

Objective

Consequences

Workaround

Proposal

Web Weekly: Vol. 5

Atomic Habits Visualized (Twitter thread)

A very nerdy perspective on naming things in programming (16 mins read)

Data centers at public pools keep swimmers warm (1 min read)

Advanced interview questions for a Ruby developer

Mini Robot Enters Blood Vessels, Completes Surgery (1 min read)

Prioritizing Tasks: ROI Over Everything