
Engineering tickets often end up meaning a lot. For the product but also emotionally for the individual. It's the engineer's job to be involved in the whole process from before the ticket even exists. Engineers refine the ticket, estimate the ticket, and shuffle it through columns on a sprint board until customers receive a feature.

The way products are built varies at every company. A team I sit metres away from at work do things so differently that there would be a learning curve if I joined them. But the concepts remain the same.

The fun part about writing this will be hearing about all the different ways y'all make software.

## Feature or fix?

A ticket can be a feature that needs to be completed, a bug that requires solving, or a chore that needs doing (e.g. code clean-up, documentation creation). A _spike_ is a type of ticket that means the situation is unclear. Perhaps it's because there are unknowns about the technical implementation. Perhaps what's required is checking where a tricky bug is originating from. A spike can sometimes mean: go and figure out what tickets need to be created to solve this problem and then create those tickets (the hydra of tickets).

In the [Agile](https://en.wikipedia.org/wiki/Agile_software_development) methodology, tickets shouldn't be time boxed but spikes are one of the exceptions. Without a time-limit, when does the engineering stop if unknowns are involved? It's far better to write down your findings and get your team's input. Sometimes spikes are easier than they seem and the development work can be completed within the time-limit and everyone is happy.

## Where do tickets come from?

Here are some ways that tickets can come into existence from nothing.

- A customer complains about a bug and a support engineer documents it
- A project manager or team lead plans a piece of the project
- Some technical debt is created while working on another ticket
- A developer realizes that their current ticket requires additional parts
- Another department (e.g. data scientists) require some work to be done

## Where do tickets live?

Most tickets exist in a sad place called the backlog. It's sad because there are always tickets in there that you want to complete. Things that genuinely improve the product (or your ease of working on the product).

Backlogs usually increase in size until they become unmanageable. At which point they can be filtered and trimmed by certain criteria. _Won't do_ is a common reason to close a ticket — as in: we realized that there is an issue here but we don't have any plans to actually fix the problem. I've seen date cut-off limits where after a year of a ticket existing if it hasn't been completed then it's put out of its misery and archived. A well trimmed backlog is the sign of a well managed engineering team.

Tickets are always archived, never deleted. If there once was a bug that then becomes a bigger bug in the future, you'll wish there was a trail to follow when it falls on your lap.

Tickets are brought out of the backlog into a refinement section. These tickets are then discussed in a backlog refining meeting. Questions are raised and answered before the ticket can continue on its journey. Sometimes the questions can't be answered and a comment is added. A comment might tag someone with a TODO like _@alice to gather more requirements from (other team who requested the feature)_. This ticket will be looked at again in the next meeting.

In a backlog refinement meeting, you might ask:

- Is this possible?
- Is this within our area of responsibility (is this another team's job)?
- Roughly, what steps are involved in solving this?
- How long will this take? 

A good rule for completing projects is: don't do something if you don't actually need to do it. This sounds silly until you realise how often it is broken.

## Estimation

[Planning poker](https://en.wikipedia.org/wiki/Planning_poker) is a ritual that helps get the average estimation for a ticket from a group of engineers. It works best when everyone reveals their estimations at the same time as this removes biases. Planning poker cards are often used because everyone can flip them over at the same time.

The unit of time is 'points' which can seem abstract at first. It's common to hear things like _oh that's just a one-pointer_ or _hm, 13 points is a little high, can we break that up into smaller tickets?_.

Planning poker cards have a modified Fibonacci sequence on them. 1, 2, 3, 5, 8, 13, 20, 40, and 100. Why? The International Scrum Institute has a [good summary](https://www.scrum-institute.org/Effort_Estimations_Planning_Poker.php):

> The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. A high estimate usually means that the story is not well understood in detail or should be broken down into multiple smaller stories. Smaller stories can be estimated in greater detail.

When tickets are pointed they can be placed into _sprints_ in a sprint planning meeting ([What is a Sprint in Scrum?](https://www.scrum.org/resources/what-is-a-sprint-in-scrum)). A sprint is a time frame where a goal is worked towards by completing tickets. Traditionally, a working product is demoed to stakeholders at the end of a sprint so that it can be worked on iteratively taking feedback into account.

One sprint follows another. At the end of a sprint there are reviews and retrospectives to ensure that the ways of working are productive and pleasant for everyone involved.

## Interacting with tickets

When I pick up a ticket, I move it to a column called _In Progress_. This automatically assigns me to the ticket and puts my avatar in the corner of the card. This stops people doing duplicate work and helps product managers and quality assurance engineers see who is working on what.

Sprint boards usually have a column for tickets that are in review. GitHub notifications can get lost in a sea of other emails so being able to see what work I can review for my teammates really helps me.

The act of dragging these small cards in the sprint board's UI feels significant. Moving the ticket through the columns, left-to-right, indicates and broadcasts the ticket's progress. The final column, which means the work is done (meaning deployed to production or handed off to another team) is a happy place.

Good tickets are written so they can be scanned efficiently. They use [Markdown](https://en.wikipedia.org/wiki/Markdown) to achieve this by marking sections and highlights. Bullet pointed lists are used in abundance. Good tickets also probably have:

- A user story — the requirements from the POV of a user
- Technical requirements if relevant
- Links to other relevant tickets or previous work
- For front-end tickets, links to designs
- Tags! Tags give the team visibility into blockers and future problems

I like to keep tickets updated so that stakeholders don't need to chase me for an update. I do this by leaving comments about my progress.

I've normally been lucky at companies I've worked at in that code reviews are integrated to the issue tracking system. So 'attaching' a pull-request to a ticket is effortless and is achieved with a single click or comment.

## Document the world

I like documentation. I like the flair that people add. Emojis, GIFs (practical or memes), and embedded videos. I spend a lot of time thinking about the best way to communicate ideas and problems — and I'm very happy that software engineering has allowed me to work on writing for humans. Lean writing that conveys a point. The least words required.

Some days I will be adding comments to technical designs, or explaining a pull-request that grew in size and requires a lot of context to understand. Other days I'll be breaking down a technology for the wider team by assuming the reader has minimal coding knowledge.

If you go the extra mile to throw up an internal documentation page after solving a problem, I appreciate you. I see you editing the onboarding documentation, keeping it tight, the instructions clear and friendly, and I thank you.


Engineering tickets often end up meaning a lot. For the product but also emotionally for the individual.

The Flow of Knowledge in a Team (or Why I Dig Tickets)


Madeline and I moved our living room around so our desks could be up against the blinds in the lightest area. We have our full work setups here. We carried the gear home in a duffle bag and went back a week later for the [chairs](https://en.wikipedia.org/wiki/Aeron_chair) which, while being amongst the most ergonomic objects I've ever touched, rattled like heck as we wheeled them home.

![Our living room, a sofa, rug, long desk, two setups](living-room.jpg)

When we have meetings at the same time, one of us normally goes into another room. It depends on how much we're speaking. When we're both talking we tend to get louder and louder, without realizing it, until we're almost shouting.

This is where I listen to lofi hip hop streams and build software and record GIFs to make my pull requests all pretty. My MacBook Pro 2019 is paired with a small £12 bluetooth keyboard because my work keyboard won't fit comfortably on the kitchen table.

![Laptop, a small keyboard](laptop.png)

Last week, I was in the other room and Madeline pranked me by turning the brightness and volume up and down on my MacBook via this keyboard (which I had left behind). I was in a casual call with someone at the time and I was describing, while bewildered, all of the weird symptoms until I heard Madeline stifling laughter on the other side of the door.

I spend a lot of time on Slack, Google Hangouts, and Discord. On Slack, my team has a private team channel for work memes and things that relate to the [sprint](https://en.wikipedia.org/wiki/Scrum_Sprint). I find that when working remote, it's best to have conversations in channels rather than private messages because this shares knowledge and context among the team. Messages in channels are also searchable by the team (even though Slack's search feature leaves much to be desired). I found that it was worth learning a few Slack shortcuts to increase my productivity e.g. CMD+K to quickly navigate, UP ARROW to edit your last message.

We use Hangouts for our regularly scheduled meetings, all synced by Google Calendar. Hangouts has slightly worse quality than Zoom and seems to use up more battery. Discord has been great for pair programming. The stream feature is being improved almost every day. Discord is better for when I'm working closely with someone on a feature but we only need each other every few minutes. In between these moments we can go silent or just idly chat.

I've been quite into videos from a train driver's point of view. They're long and uneventful and beautiful. I leave these 12hr streams on my third screen. These videos are often from Norway, where there is the [slow television](https://en.wikipedia.org/wiki/Slow_television) movement.

The usual meeting schedule, and the cadence of our sprints, is the same as before we all went remote. Before, we each worked 1-2 days remotely each week so the transition hasn't been too bad. I have been trying to be positive and I've been looking forward to reviewing our remote practices for when we get back to the office. It's always been a priority for me to make sure that anyone remote is included fully in discussions and activities at the office.

One trick for connecting the remote person to office life is to let them lead the daily standup while they share their screen (usually viewing the sprint board). This ensures that the remote person understands everything that is going on and feels comfortable asking for clarifications. It ensures that everyone is conscious of the microphone setup at the office too (for when there is one shared microphone e.g. a standup meeting). Alternatively, everyone at the office can dial into the meeting separately to make it a level playing ground.

![Richmond Park](richmond-park.jpg)

At lunch Madeline and I usually go for runs in Richmond Park. We work hard to keep two meters+ away from people. It's been beautiful to watch the season change into Summer.

I have been drinking more coffee — cold brew and instant — especially in the mornings. We discovered the joy of barista-style oat milk (shaking the carton plenty before pouring) and it has ruined all other types of oat milk for us! It's apparently made from liquid oats (I looked it up but still don't know what it means) which keeps the milk from separating when the coffee is left still.

Deploying code has been scarier while remote. At the office there is always someone around to help with problems even though the way of grabbing them is the same (we message on Slack if someone's headphones are in). However, the only problem I've run into is GitHub being down, which can affect our CI/CD systems. I'm lucky that Madeline works at the same company as me. She's in a different team but we have been sneaking in some pairing sessions and helping each other out. I've learned more about the area that her team works in. Our teams sit a few meters away at the office but our processes are surprisingly different. It's been fun to learn what works for them and then to take it back to my team. Madeline and I have been speeding up each other's features by calling out questions across the kitchen table when we're stuck.

A junior co-worker told me that they are googling more and getting less stuck because they aren't embarrassed by the idea of other people looking at their screen. I told them that I sometimes barely understand what is happening on my screen let alone anyone else's screen in the vicinity. They also told me they are learning quicker because they are seeking out help less.

My work tickets lately have been all over the stack, touching a little bit of everything. It's been fun and keeps things fresh. I hope soon to be able to deep dive into a technology like I did a few months ago when we shipped a Vue.js prototype.

We have a moodboard at the office — a big whiteboard off in one corner with a grid of days and people's names. We draw pictures, or write words, to describe our days so we can look back in [retrospective meetings](https://en.wikipedia.org/wiki/Scrum_(software_development)#Sprint_retrospective) (once per two-week sprint). Before, when it was rarer to be remote, we sometimes had people describe their moodboard drawings for someone else to quickly sketch up which I enjoyed doing even when my doodles came out goofy. Now, we have moved to a fully remote moodboard with Miro. Which means we can use GIFs! On Miro, you can also see ghost-like cursors, belonging to faraway engineers, move around the shared board.

Our plant growing has extended to things that are consumable. With garlic, onion and spring onion, as well as pak choy, we hope to grow enough to make one meal within lockdown! It is meditative to care for them. I have lost count of the things that are growing in this apartment. And I'm thankful that Madeline is the main waterer.

![Potted cloves of garlic](plants.jpg)

The bi-monthly hackday was held remotely and Madeline and I spun up a _QUAKE III: Team Arena_ server from scratch and deployed it so that we can use it for the #gaming Slack channel at work. We used to have the server hosted on someone's laptop. Our humorous presentation was about client/server latency and why the person hosting the game had an unfair advantage. We also started building a Vue.js app to help us keep track of goods around the house that we buy on different schedules e.g. kitchen roll, and black bin bags but ran out of time to fully flesh it out.

I've been reading more in the evenings. I bought The Electric State by Simon Stålenhag after admiring his art on Twitter. I've been reading articles from [Lobsters](https://lobste.rs/), [Hacker News](https://news.ycombinator.com/), as well as The New Yorker — I really liked [The Friendship That Made Google Huge](https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge).

Hope y'all are staying safe 👋


Writing code, working (almost) solo, and exploring remote-life during the UK lockdown.

How I'm Working Remotely


I'm in year two of technical blogging and I've learned a lot. I have far _far_ more views and comments than I thought I would at this point. At the beginning I was throwing my thoughts into the void and it felt good. Reading [**The Developer's Guide to Content Creation**](https://www.developersguidetocontent.com/) reminded me of those roots. It inspired me.


I love seeing people blog about their passions and thoughts especially when it's on a personal website. Personal websites are cool and weird and make the internet more enjoyable for me. If there's a link in your bio there's a high chance I'll click it.

So I'm very happy, on this quiet and unusually cold Sunday, that there are resources for those who are starting out on this journey!

## The Best Beginner Introduction to Blogging

Without a doubt [The Developer's Guide to Content Creation](https://www.developersguidetocontent.com/) is the best resource for those looking to start writing content for developers. Before reading it, I had a shortlist of topics that I thought such a resource should cover and it nailed every one. Morillo's writing is clear and engaging. She tells us how to write content that is accessability in presentation but also in content. She reminds us how not to write as well:

- _"Just follow these simple steps"_
- _"It’s easy to put together"_
- _"The answer is obvious"_

> I’ve realized that many writers of technical content use these words to make the subject matter seem less intimidating to the reader. They genuinely want to remove friction for their users, but they’re using language that makes the reader feel like the problem is with them.

## Rich in Resources

The Developer's Guide to Content Creation also contains copious amounts of worksheets to inspire you, help you strategize, and put together a content calendar.

There are resources linked throughout the book that compliment each section. There's also an example of _how_ to insert resources into an article in a more descriptive manner. To mirror one of Morillo's examples, take GitHub's trending page.

- "GitHub has a list of trending repositories. Check it out [here](https://github.com/trending)."
- "[Search through GitHub's list of trending repositories ](https://github.com/trending)."

For a reader, the second version flows better.

Morillo recommends comprehensive resources like [DigitalOcean's Technical Writing Guidelines](https://www.digitalocean.com/community/tutorials/digitalocean-s-technical-writing-guidelines) as well as tools that take seconds to set up and run on your writing.

> [AlexJS](https://alexjs.com/) is an open-source tool that will help you "spot insensitive, inconsiderate writing."

> [Hemingway App](http://www.hemingwayapp.com/) is an online editor that helps you simplify your writing. It highlights confusing sections, areas that are too long, and more.

To add my own, reading other technical blogs can be a good resource and I'd recommend Hacker Noon's [shortlist for Personal Developer Blog of the Year](https://hackernoon.com/personal-developer-blog-of-the-year-hacker-noon-noonies-awards-2019-hz2tu32ql) to get started. Drew DeVault posts [great content](https://drewdevault.com/) and [will occasionally pay out $20](https://drewdevault.com/make-a-blog) to people starting a technical blog on an open platform (i.e. not Medium). Google have also released a free [course on technical writing](https://developers.google.com/tech-writing) although I believe it's aimed more towards those writing technical documentation.

## The Shape of a Post

Morillo talks a lot about how technical blogs are consumed and how they appear to users.

> Before you start writing, you need to understand how people read online. People don’t read every word and every sentence; they scan. They’re scanning for the most relevant information and things that pop out at them will command their attention.

Thinking about the shape of a post can help during the editing stage. It's a way to cut through complexity and grab readers who would have otherwise failed to skim read blocks of text and given up. It also helps those who come to your post only looking for that one line of code that will unblock them.

We're reminded that people scan for "keywords, section headings, bullets, anchor text (when hyperlinked), words that are bolded or italicized for emphasis".

<br>

The Developer's Guide to Content Creation covers topics that were getting dusty in the back of my mind as well as delivering a nuggets of wisdom. Even as I write this post, I'm considering Morillo's advice. It's for this reason that I would recommend this book to anyone writing content for developers no matter their experience. It has changed the way I will approach writing for my personal blog as well as for my company's blog.

Following this book, Morillo is currently writing [The Developer's Guide to Book Publishing](https://www.developersguidetocontent.com/book-publishing-guide) — I'm looking forward to it!


Discussing an amazing resource for those writing for developers.

Book Review: The Developer's Guide to Content Creation


I learnt about pair programming at university when we were studying Agile methodologies. At the time it seemed very full-on — almost scary. I pictured myself stumbling over my keyboard as my co-worker facepalmed behind me. In reality, pair programming sessions have helped me to evolve as a developer and I actually find it more relaxing to tackle something as a team of two.

![Some fast-paced pair programming](fast-pair-programming.gif)

> Do you mind if I drive?

_Driving_ means being in control of the mouse/keyboard. _Navigating_ is watching, and depending on the pair's style, might be dictating what is to be written or there to raise questions, problems, and muse on design. Find a more detailed break down of the roles [here](https://gist.github.com/healeycodes/5acc53131957f6a96a281c89890c7706) (first written by Jordan Poulton).

I saw a study which claimed that during a conversation we give the other person around three times longer to respond to us than we give ourselves when it is our turn to respond. I think that the same holds true while pair programming because I've felt under pressure at times. I can remember plenty of instances of myself making endless typos (that I missed until they were pointed out) and forgetting basic structures of code, worrying that the navigator was getting bored while waiting for me to finish my code-thought. However, I can't remember any of my co-workers ever doing anything of the sort. Everyone has uniformly been brilliant.

It may seem odd to the uninitiated that two developers working on one ticket can be more efficient than if they were working on two tickets separately. One of the reasons is the level of focus and that can be maintained by the driver. Someone watching you code will catch silly errors that your linter might not. This saves building and testing time. Instead of googling easy questions (and context switching) you can throw them behind you and stay in your IDE. Being able to discuss ideas helps with creative problem-solving. I find that my mind wanders less because my partner is always there to point me back to our design. Rabbit holes can be nipped in the bud — e.g. one of us saying "Let's not optimize this part yet".

For me, it's a comfy atmosphere, it's fun. I've seen it referred to as an "automatic bi-directional rubber ducky".

When debugging, the best course of action is to break the problem down to its smallest parts — removing assumptions and finding out which parts you know for sure 100% work. However, it's hard to get rid of your own assumptions and later on you'll find out that something you held to be true was, in fact, the path to the solution. While pair programming, it's easier to approach the problem with more logic as there is a second pair of eyes that must be convinced of every assumption being held.

Pairing is good for when:

- You're stuck!
- You're new and want mentoring
- The team needs shared knowledge
- There is one time-sensitive feature

### Some tickets don't require it

I've read about peoples' experiences at companies where _every line of code_ is pair programmed. I'm curious about the benefit of such a requirement. I imagine that the [bus factor](https://en.wikipedia.org/wiki/Bus_factor) of a team would be incredibly low. But I'm thinking about the stories and bugs where I'm working in parts of the codebase that I know well. Where most of the work is setting up boilerplate code and some tests.

My favourite setup that I've experienced so far is a team where pair programming was left up to the developers. If we felt that a ticket required pair programming to be efficient then all we had to do was let our manager know that was the plan.

### As a mentor

Over the past year, I've been teaching my wife how to code. The largest jumps in her knowledge are when we've tackled a feature or a project as a pair-team. It gives me a chance to observe how she goes about tackling a problem and lets me guide her down the right path (or at least close to it). While I'm driving, the most helpful things she's reported watching are the steps that aren't coding but are more knowledge-based e.g. setting up a dev environment, proper version control, different test suites and CI/CD integrations.

### N.b.

This reads a little like propaganda from the Pair Programming Institute (tm). Some people don't mix well with pair programming and may find it distressing and inefficient. And there's nothing wrong with that at all!

My Experience with Pair Programming


_"You should contribute to open-source." ⁠— The Internet._

Maybe you've seen this advice. Either from those who believe in free software — or as a suggestion to aid job seeking. Many people (some of my mentees included) report that GitHub is scary. The projects on there are mammoth-sized compared to any team project they've worked on. The people working on these projects are, like, _serious people_.

This is true and this is not true. There really isn't anything to worry about. Let's talk about what's involved. I'll be using my _tiny_ [contribution](https://github.com/jekyll/minima/pull/379) I made to Jekyll yesterday as an example. There are [lots](https://www.firsttimersonly.com/) of resources for finding first-timer issues but there are a few steps that these guides miss out on.

## Find a problem

It's going to be easier to find (or remember) a bug in the software that you use every day compared to getting up to speed with a project you haven't heard of before. Let's take Jekyll's minima theme for example. Way back, I wanted my website to look different but I didn't have the time to write a theme from scratch — so I've been [hacking away](https://healeycodes.com/) at this theme for a while now.

This is how I found the bug. I went into developer tools (F12) and set the view-size to be _iPhone 5/SE_, which is relatively small by modern standards, to test a page of my website. Some developers won't be considering devices of this size (but they should). I saw that the responsive footer wasn't appearing correctly. Instead of two stacked columns, there were two columns and one was empty.

![Minima broken columns](minbroke.png)

At first, I presumed that some of my hacking must have caused this. So I went over to the [jekyll/minima](https://jekyll.github.io/minima/) repository to double check the live demo page. I found the same problem (note: this problem is now fixed on master). The problem was an erroneous class — `.one-half` which was not behaving responsively. (I discovered this through some Dev Tools tinkering).

It needed a [media query](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries). Media queries are how our websites change styling depending on the device's settings, e.g. resolution. __You don't need to understand the whole tech stack behind the project you're fixing__. For example, I haven't used Sass that much but I knew about its CSS variable system. I looked around for a breakpoint variable that was already being used and which complimented the footer columns at all sizes. I settled on `$on-large` — resulting in a fix to the problem.

![Minima fixed columns](minfixed.png)

## Fork the branch

Check the contributing guidelines. This is more important than any advice I can give you. For jekyll/minima, the [guidelines](https://github.com/jekyll/minima#contributing) were pretty simple: "Bug reports and pull requests are welcome," as well as a link to the code of conduct. It should also tell you which branch to send your changes to.

jekyll/minima is developed on `master` but usually there will be a staging branch for you to fork. Head to the GitHub repository in your browser and click the _Fork_ button, then clone the branch to your computer. The community recommends learning the command line tools for git interaction but the [GitHub Desktop](https://desktop.github.com) client works fine too. If there's a test suite, run the tests before changing anything to ensure that your environment is stable.

## Create a pull request

Make your changes and [write a good commit message](https://github.com/erlang/otp/wiki/writing-good-commit-messages). Mine was "Fix footer stacking issue for smaller view sizes". Push the changes to your fork. There are ways to create a pull request via command line but I visit my fork's repository and hit the _Pull request_ button at the top right of the file list.

I've always thought that writing a pull request is just as important as the code. If your team members can't understand the proposed change at a high level then they won't be able to critique it successfully. Meaning that your pull request could be denied (or accepted when it shouldn't be). For bugs, I describe the bug, include an image if appropriate, then explain what changes are required to fix it. If there are important, tech-y implementation details then I place them at the very end.

Perhaps a final look over the contributing guidelines (check `CONTRIBUTING.md` if you can't find it) and then it's time to submit. Check how often pull requests are being read, commented on, and merged. Make sure you understand how long it may take for a response so your expectations are met. (For my [small fix](https://github.com/jekyll/minima/pull/379) it was less than a day).

## Handling criticism

You may want to tick _Allow edits from maintainers_ to make small stylistic changes easier to happen. A GitHub user thanked me for my change and saw that there were further fixes in the area I was working in. I had a look but couldn't come up with a clean solution to the extra fixes. For the extra fixes, a small architectural rejig was required and I didn't have time to further study the code base. Basically, it's okay to say no — we're all volunteering our time here.

Separate yourself from your pull request. Your code does not represent _you_. For example, you may not be familiar with design patterns used elsewhere in the project. The worst thing that will happen is someone advising you to try again. You'll be shocked at how helpful and welcoming people are in the open-source community.

We want you to succeed! If you're experiencing pull request anxiety, throw up a one-line change on one of my [toy projects](https://github.com/healeycodes). I'll greet ya with a smile 😊.


Making a small change to the Jekyll project.

Your First Open-Source Pull Request: a Walkthrough


My B.A. is in Creative Writing. I applied to study a Masters in Computer Science to get better at theory, fill the gaps in my knowledge, and to be a better software engineer. Here are a few things that weren't on the curriculum.


### Markdown

Using [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) is straightforward and can be learned in fives minutes. However, effective use of it is a little harder. Writing good technical documentation is a separate skill to Computer Science. Have you ever visited a repository on GitHub and the README just clicks with you? Your questions: answered. Your eyes: rewarded.

Directing where a visitor looks and shaping their experience of your text is something that is understated. I've been asked to review portfolios and have found fantastic libraries with textbook clean code and patterns out the wazoo. But all of this hidden behind a cold markdown page with minimal formatting. A few short sentences squashed together doing zero justice to the beautiful code a few clicks further. Most hiring managers would have stopped right there.

Studying Computer Science in academia is quite separate from the reality of programming, which is all about humans connecting. We write code for humans, not machines. No one wants to start reading code without an intro. A nicely marked up README softens the blow — and will [help you get that job](https://dev.to/healeycodes/how-to-write-an-awesome-github-readme-2ldc).

### Clean code

With deadlines looming and marks not awarded for neat code, it's hard to learn to write code cleanly. Going through a few review processes at my first job shaped me up fast though. There's a big difference between writing code for a professor — with the only requirement being that it works and is 'readable' — and writing code for a team that you care about. Projects in academia are built and thrown away for the most part. We all grumble about the code behind some fantastic papers. (Although, a few of my classmates did open source [parts of our projects](https://github.com/healeycodes/websocket-benchmarker)).

People have their own definition of clean code. For me, I'm interested in writing something that can be easily extended or altered in about three to four months. Code with comments only where necessary, cached variables to help cohesion, everything formatted per the style guide and then further for readability. I wish someone told me at school: don't forget the human.

### Code review

While there were one or two opportunities to work in teams, it wasn't a high priority to set up a code review process. All coding — from [launching spaceships](https://coder.today/tech/2017-11-09_nasa-coding-standards-defensive-programming-and-reliability-a-postmortem-static-analysis./) to writing iOS apps — will involve reviewing other people's code and preparing your own work for review. There are two parts here, reviewing and being reviewed.

Reviewing code is a practice in building mental models and applying empathy. If you're reviewing properly, you're not only concerned about how the code reads line by line but how it affects the code base today and also this time next year. You have to ask questions and provide feedback with the utmost empathy. You are not a scorned theatre critic — you are trying to help your _teammate_ improve their code. Be polite, err on the side of being courteous. Though, when you have a rapport, slather on those GIFs.

Preparing code for review is a skill in itself. Your review should be a logical chunk. As small as makes sense. Describing the problem or story your code is solving is important too (I personally use markdown for this). It will arm your buddy as they go to battle in the depths of an attempt at your first bug (sorry, Jamie). It will save them rolling their chair over to you and going _so about that review_.

### The edges of languages

At school we applied languages like Java, JS, and Python, to solve algorithmic problems. We built databases, management systems, navigated mazes, and touched a bit of full stack too. We optimized. We did all this with the core tools. Data structures, algorithms, Object Oriented Programming, and a dash of math. However, I had to learn on my own how `setTimeout`, `delete`, and `this` interact inside a production code base. No one told me about decorators, or how ES6/7/8 was bringing us into the future. I like bugs that take me somewhere I haven't been before — when I crack open the spine of StackOverflow, the esoteric and unknown interactions. For JavaScript, I can recommend [You Don't Know JS](https://github.com/getify/You-Dont-Know-JS) and [Eloquent JavaScript](https://eloquentjavascript.net/) (both free). For Python: [So you want to be a Python expert?](https://www.youtube.com/watch?v=cKPlPJyQrt4).

### ~

Although I worked hard, I learned more by trying to be [creative on the web](https://github.com/healeycodes), entering [game jams](https://healeycodes.com/projects/), and hacking away at weird projects. I pretty much consider myself to be self-taught except I'm lucky enough to put the letters _MSc_ on my resume. The skills that I used to consider paramount have fallen away. I once thought being a programmer was all about eureka moments and collecting a library of algorithms in your brain.

When I hear that someone new is joining our team, I don't worry how good they are at writing code. I want to know that they'll listen to my comments in their review (and tell me how I'm wrong!). I want to be able to communicate with them about technical subjects. I want to learn from them but not just about code-related things. Most of all, I hope they are fun to work with.


What They Don't Teach You at a Computer Science Masters


The following isn't good advice. It's just _advice_. And even that's a stretch.

I used to be really into those productivity hacks. No zero days, Pomodoro, writing up your goals for the day, starting a task for five minutes, etc. Eventually, they merged into a document of rules. I wanted to work as a coder. I had digested all of the advice I could take. Blogs and READMEs, complex graph charts that spider out describing your career in buzzwords you don't even know yet. Enough of the analysis paralysis, I said, and typed up some rules in a small London coffee shop. To these, I stuck.

The following sections describe some of these rules and the results (interviews, job offers) but do note that my success is probably unrelated to every word printed here.

### Write code in two languages every day

For me, this was JavaScript and Python. I was aiming for full stack and back end positions. If I was stuck on my projects, I would code up data structures from scratch in both languages. The repetition helped them stick. I wanted to be ready to write relatively clean code in either language without any preparation, should I be called to interview. Solving problems that are challenging to you is never a waste of time if your goal is to learn.

Sites like [LeetCode](https://leetcode.com/) and [HackerRank](https://www.hackerrank.com/) have questions that you can sort to get progressively harder. What's important is that you realize that the goal is not a correct answer — it's _understanding_. Pushing at the edge of your knowledge should spawn mini study sessions where you chase down different implementations of the solution so you understand the whys and hows. I found that personal blogs always had the best break-downs.

### Read yourself to sleep with a textbook

If you've seen my other writing, you'll know that I won't stop recommending _Grokking Algorithms_. I chose the Computer Science textbooks that I enjoyed, not necessarily ones that would help in my job search. These books didn't have to have code or math in them, e.g. _Code: The Hidden Language .._ or _The Mythical Man-Month_. A lot of the stuff I did during my job search was to get in the right headspace. This is embarrassing to say but I did the things that I pictured a good software engineer doing. Which I suppose is like wanting to be a good basketball player and spending your post-practice time standing in center court just staring at the hoop. It's good to just rest some times, ya know.

### Study interview question trivia every day

I wasn't trying to memorize, which would have felt cheap, I was trying to understand what these questions implied in order to direct my learning. They are asked for a reason. `setTimeout` trivia questions are really about asynchronous programming and the Event Loop. I had to know the answer and be able to speak about the subject it represented. These sessions were scary first as they further revealed everything I didn't know (and still don't!). 

Not often will you have to call `delete` but it's good to know what it does and _doesn't_ [do](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete) (I was asked about this in an interview). Searches like `most popular JavaScript interview questions` will find you the lists I'm talking about. These questions can get pretty esoteric so your mileage may vary.

### Three testable projects with instant interaction

Three felt like a good number. I worked backward — coming up with the blurb and the bullet points for the projects on the resume first. Building the projects came second. They each needed a test suite, e.g. `npm test`, `pytest`. In my mind, good engineers test everything. I suppose I still believe that. Getting tests written early on speeds up the later stages of development.

What do I mean by instant interaction? I guessed that someone reviewing my resume would spend about four seconds per each hyperlinked project — and that most wouldn't even click. I hosted all three projects on a Digital Ocean [Droplet](https://www.digitalocean.com/products/droplets/), local to my region. Digital Ocean have some great guides for getting started with Linux too. I didn't want to use free options, like Heroku's free tier that sleep when not in use and have to wake up when a visitor arrives — there go my four seconds.

Once they arrived on the page I wanted them to be able to interact with the core idea of the project instantly, e.g. no sign-up or authing required. I'll skim over my projects to give you a better idea.

**CodePen Teams Clone**

I was (and still am) very into pair programming and created a low latency solution for remote collaboration coding. I cloned the design of CodePen but piped the display data over WebSocket to the whole room. Teammates could see live edits in about 25ms. Rooms could be forked too. When arriving on the home page, the _Create Room_ button was front and center.

**Game Jam Highscores API**

This was a free solution I ran for a few years for game devs to instantly set up a highscores backend by just calling our RESTful API. Upon loading the home page, you were greeted by your API key, and there were links prefilled with this key to test out the features.

**Lightweight Google Analytics Clone**

I cloned Google Analytics in the most basic way possible, allowing people to roll their own analytics. The angle was privacy-friendly and people were only tracked for 24 hours. I linked to the demo page on my resume, with animated graphs that popped up with page views, unique visitors, avg. time on page, bounce rate.

Back to the rules.

### Read ten resumes a day

People post tech resumes all over the place but I found the most high quality were on [r/cscareerquestions](https://www.reddit.com/r/cscareerquestions/). After all the studying, whether you got an interview or not was almost totally weighted by your resume. Reading all these resumes helped me understand what my own was competing with. It gave me ideas for sections, page design, and even projects. I also helped out by pointing out grammatical errors wherever I saw them. I took my time with them — even printed them out sometimes and marked them with a pen. There's historical precedence for this kind of behavior, Hunter S. Thompson typed out the entirety of The Great Gatsby and A Farewell to Arms (on a typewriter no less!).

### Cover letter with genuine connection

Cover letters seem to be more beneficial over here in the UK. I count the little text boxes that companies offer with your application as a cover letter too. I fought hard to write something genuine as I really believe that sincerity wins over everything else. I liked to read the company's tech blog if they had one and if not I often checked out the source code of their website and tried to find interesting things to comment on. I even found a leaked API key once. In most of my interviews, topics from my cover letter were brought up.

### Pace and plan for phone interviews

Print out everything beforehand and lay it out on the bed. The job post, my personalized resume for that job, the companies bio page, the interviewer's LinkedIn (although, don't allude to this) — it helped me understand their background and seeing their face was relaxing. It helped remind me that people are almost unanimously friendly and want you to succeed. I've always paced around the room for phone interviews. I alternated between pacing and lying flat on my back.

### Travel to interview location the day before

I traveled down to the interview's location the day before so that part of my journey would be stress-free. I visualized myself interviewing, getting the job, and working there — like I was going on my new commute. Being familiar with the area made me more comfortable when I ended up in the room and that's what it's all about really. An hour or so snapshot of yourself. Nothing could prepare me for getting lost in the building though, which actually happened twice.

Following my application, I ended up with a phone interview rate of 10%, all of which invited me to interview in person. I approached test projects with the same obsessive gusto I've unfortunately shown in this article.


The Weird Rules I Set Myself That Got Me a Job


I read through the earliest README I could [find](http://pdp-10.trailing-edge.com/decuslib10-04/01/43,50322/read.me.html). Written in 1975 by William J. Earl at the CS department of UIC. The text is a little dry but also surprisingly relatable, some 44 years later. _"Due to a bug in the compiler, this function does not compile correctly"_.

A README is a reflection of how a repository is maintained. A good one doesn't necessarily mean an active, bug-free project with perfect tests. But it suggests that the owner cares about **you**, the user (or future maintainer). A good README tells you everything you need to know to use the project and get involved. It _sells_ the project — but concurrently respects a visitor's time by letting them know if they need a different solution.

When using your GitHub profile as part of an application, READMEs are important in a different way. They showcase technical writing skills — the ability to communicate well and put together a software-related document. Expecting someone to dive into your code without providing an abstraction explaining the project is a pretty big ask.

## Clear description

Someone should be able to use your software without reading a line of code.

First, change the default title that GitHub provides — turn `python-ml-project-for-cat-lovers-2` into `Cat Crawler - Classify Cat GIFs`. The next step is explaining your project in its simplest form. Many people use a one-liner at the very top.

> A bot that downloads and indexes Cat GIFs

As you add more content to your lead description, you raise the chance of cognitive overload. After editing the language down, use titles, line breaks, and spacing to further break it up. (Two new lines for a new paragraph and `<br>` for a break. [Cheatsheet](https://help.github.com/en/articles/basic-writing-and-formatting-syntax).) Don't shy away from product logos and screenshots. Unlike other technical documentation, multimedia performs well here. For the more esoteric repositories, a background reading section can help.

If your repository is fun or lighthearted then your description should show this! [Strunk & White](https://en.wikipedia.org/wiki/The_Elements_of_Style) have their place but the internet is also a hangout for cool coders being creative. Shoutout to [not-paid](https://github.com/kleampa/not-paid), which slowly fades a website until it becomes invisible at a certain date, should the client not pay their dues.

## Usage

How does someone use your project? If it's an API, have a section of code with the most basic interaction. Your full documentation can be further down the page or at another location. [facebook/react](https://github.com/facebook/react) shows their usage with an example — the smallest way someone could use React. Use single backticks to quote code, and three backticks on new lines for codes blocks. Put the language right after the first three backticks for specific highlighting.

```jsx
function HelloMessage({ name }) {
  return <div>Hello {name}</div>;
}

ReactDOM.render(
  <HelloMessage name="Taylor" />,
  document.getElementById('container')
);
```

Show the output of this interaction. If you can use a GIF in any way then do so! GIFs are easy for humans to parse and they transmit a lot of data into your reader's mind. [alexfoxy/laxxx](https://github.com/alexfoxy/laxxx), a library for smooth web animations, does this perfectly.

![alexfoxy/laxxx](laxjs.gif)

I use the open source tool [ShareX](https://getsharex.com/) to create my GIFs. It's as simple as selecting an area of your screen. Another solution I recommend, also open source, is [LICEcap](https://www.cockos.com/licecap/).

## Installing

Hopefully, after seeing your project in action, your visitor wants to install it. This section is sometimes titled as _Getting Started_. Every project should have this, even if it's just `npm install catcrawler`. If it's a static site then say so! `host the parent dir on a webserver`. Assume knowledge of the basic tools. You don't need to explain what `pip` or `npm` is but you should list every command that you would run on a new setup.

[DEV](https://github.com/thepracticaldev/dev.to/#getting-started) has a thorough section for getting a build up and running, which is a great model to follow if you're aiming to be accessible. It's good practice to spin up a virtual machine and try to replicate your installation guide — assuming you don't have automatic build tests to do this for you.

## Badges

![example badge](example-badge.png)

Mostly standardized by [badges/shields](https://github.com/badges/shields), GitHub badges are one of the first things a visitor sees as they scroll down. Build status badges describe the stability of a project. Other badges might show the activity of a repository with commits per month, or the number of maintainers. They aren't compulsory but much like GIFs, they are a huge bonus.

[shields.io](https://github.com/badges/shields) have an API for creating your own badges, and they also have an npm [package](https://www.npmjs.com/package/gh-badges) which is pleasant to use. I picked it up a few weeks ago and had some badges up and running in under an hour! Another npm alternative is [badger](http://badges.github.io/badgerbadgerbadger/). Python has [pybadges](https://github.com/google/pybadges) by Google.

If you're looking to earn your first `build: passed` badge, I wrote an [article](https://dev.to/healeycodes/earn-a-build-passing-badge-on-github--testing-your-express-app-with-travis-ci-1m2f) here on DEV that walks you through getting started with continuous integration on GitHub.

## Contributing

If you're seeking them, a section for contributors is helpful and welcoming. There is a GitHub [standard](https://help.github.com/en/articles/setting-guidelines-for-repository-contributors) for adding a `CONTRIBUTING.md` file to the root dir. This may include a code of conduct and general guidelines for finding issues and building a pull request. A lot of beginners are anxious about the process of helping out open source projects and walking them through step-by-step can alleviate some of this. If you're not sure where to start, I recently saw a code of conduct [generator](https://github.com/uyouthe/code-of-conduct) which I thought was pretty neat. I know that some of my friends will only support repositories with strict guidelines and rules for maintainer interaction.

## License

A license is the first thing I look for when I'm seeking a solution at work. When creating a repository through GitHub, there is an option for choosing a license which will generate a `LICENSE.md` file for you. GitHub also has a [page](https://help.github.com/en/articles/licensing-a-repository) on this file — and they are the creators of [choosealicense.com](https://choosealicense.com/), a fantastic guide walking you through all the options. I personally use MIT for my open source code. Some people have strong opinions about licensing, especially when it comes to [GPL](https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)). _"Any modifications to or software including (via compiler) GPL-licensed code must also be made available under the GPL along with build & install instructions."_

## Templates

[There](https://github.com/RichardLitt/standard-readme) [are](https://github.com/zalando/zalando-howto-open-source/blob/master/READMEtemplate.md) [many](https://github.com/noffle/common-readme) README templates out there. They're great in a pinch but I've found that smaller projects don't fit neatly into this kind of box and the resulting text comes across a little cold. Mature projects benefit more from templates but given the amount of developer time that has probably into the software, it's worth it to have a custom solution.

[This](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) is my favorite as it's straight to the point and also has two subsections on tests. If you have any tests, this should be mentioned in your README. When cloning a project, running tests is the first thing I do to make sure my setup is ready for development.

## Other sections

Once you're past all the important sections, fill your README to your heart's delight. I may be in the minority but I love browsing GitHub looking for new things and discovering how they're built. I appreciate a detailed repository with lots of example code. For me to get involved with a project, it's important to see that the maintainers care at least as much as I do.

Explore [trending](https://github.com/trending) for your programming language to get an idea for the standard layout. For inspiration, check out two of my recent favorites [Gatsyby](https://github.com/gatsbyjs/gatsby) and [lax.js](https://github.com/alexfoxy/laxxx). Most of all, make your documentation sing.


How to Write an Awesome GitHub README


After watching my flappy bird bounce and respond to my keystrokes, a fire was lit inside me. I just had completed a Unity tutorial at age 22. It had been a childhood dream to create software — to be an _engineer_. But it never really happened. So I decided to make it happen.

![Flappy bird](flappy-bird.gif)

Video game tutorials seemed pretty accessible so I kept that up for a few weeks. Brute force learning about functions, types, and classes. I delved away from the instructions and tinkered where I could but it didn't feel like I was actually creating anything, only copying. I was waiting for the results from my Creative Writing degree to come in. I had been working with some web technologies throughout my time at university but it was small potatoes compared to where I wanted to go, to where I am now.

I read an article about a conversion Masters in Computer Science. These are full Masters programmes that aim to bring passionate students up to the level of a bachelors graduate and beyond, including a heavy thesis. These courses really push you and many institutions have 'suggested' learnings for before term starts. (They're required if you want to excel). If these courses sound intense — maybe even scary — it's because they are. Often times I found myself researching concepts in order to learn other concepts in order to go back to the lecture notes!

I applied to many but ended up choosing a distance-learning MSc. I respected the institution and the alumni buzz grabbed my attention. The first modules were in Java so over the summer I prepared by completing both parts of the popular Java MOOC [Object-Oriented programming with Java](http://moocfi.github.io/courses/2013/programming-part-1/). I knew that I would be choosing any optional web-related modules so I completed most of [freeCodeCamp](https://www.freecodecamp.org/) as well. Alongside this, I was also entering game jams and creating [small games](https://healeycodes.com/projects/) in Unity with C#. This whole journey was possible with one rule: make things. Small programs, CLI programs, goofy games, silly bots.

Any fears that I had about the online delivery of my course were soothed by the active Discord chatrooms that the students maintained and the rapid pace at which professors would reply to questions — as well as the interactive live-streamed lectures. A year-long intensive course was exactly what I needed to support everything I was learning from building my [own applications](https://healeycodes.com/projects/). The module choices were flexible but still forced us to learn the fundamentals like algorithms and data structures, databases, and practical software development.

Before long, I had to start thinking about applying for jobs. This is where things got scary. Everything I had done up to this point was without risk. If you study hard, you usually get good grades, if you keep trying to build toy projects and don't give up then you will usually succeed. But applying for jobs? Interviewing? Failure is part of the process.

I stepped away from the safety of my fun apps and curriculums and I built three portfolio projects. Each one aimed to solve a problem that I or someone else in my community was facing. They were all full stack and unit tested, they had databases attached and were hosted on real servers at real hostnames — I wanted all the trimmings. I ended up building a website analytics service, a low-latency pair-programming solution, and a website for enabling game jam developers' to track user highscores. All open sourced.

Cover letters seem to catch a bunch of flak online but I think most of my interviews were related to the personal paragraph or so that I wrote for each company. If I didn't feel like what I was putting down was sincere then I started over. Often, the things that I spoke about were brought up on the phone or in-person. I applied country-wide and had a ~10% response rate for phone interviews. I spoke to hiring managers as I paced around my room and surprisingly passed all of them. I stayed up late working on coding tests. Chipping away at the rockface of documentation. The timed algorithm tests caught me sweating too.

In-person interviews were more exciting. After all this time, I finally got to speak to real people about my programming passions! I had been couped up in my room for so long that I probably came across as over-excited. I failed most of them. Which was the wrong way to think about it at the time. There are some interviews that you just can't pass. I walked out of each one thinking: that was the one. Each one felt perfect until the email finally came.

The interview that I ended up passing (for the job that I came home from earlier today) felt like every other one. I walked out grinning and called my fianceé and told her that this one, _this one_ was different. She laughed, hopeful but cautiously optimistic. I was surprised that my last-minute reviewing of HTTP status codes paid off — that part felt a bit surreal.

I've been studying and coding ever since. In my last post, I spoke about what my [day-to-day life](/webdev/career/javascript/2019/03/14/day-in-the-life.html) is like at this office. In my next, I might write about what I think makes a good portfolio project 🕹️.


An overview of how I learned to code. Also a bit on my experience during my CS Masters.

How Flappy Bird Got Me My Start in Software


*This blog is for my past self who worried about what they would be doing day-to-day after graduating.*

Last year, I completed my Masters in Computer Science and I've been working as a full stack software engineer ever since! I'm going to talk about how I work on projects outside of work, how I get my tasks done at work, and the miscellanea in between.



#### 7:00am

An iPhone alarm, maybe two.

#### 7:10am

I eat cereal and read [hackernews](https://news.ycombinator.com/) and some programming subreddits, as well as tech/regional news, and some Twitter. Sometimes I'll tweak one of my projects, something small — a docstring or a section of CSS — and push those changes to GitHub. It's good to continuously work on projects and carry them around in my mind so that ideas can come to me throughout the day. I use [GitHub Desktop](https://desktop.github.com/) at home because my branches don't get too complex, and it's great for reviewing small diffs.

#### 7:30am

I wake my fianceé with a coffee. She's a heavy-sleeping student who depends on a large cup to start her day.

I cycle to work and it takes around 15 minutes. There's a cycle path most of the way. If it's raining, I'll have a change of clothes in my bag but I don't change very often.

#### 7:55am

I'm usually the first person at the office and I turn on the lights for the engineering section. I catch up on any emails that I missed yesterday evening. I leave earlier than most and don't have any work communications on my phone.

I like to start the day by reviewing code. So ideally there are some fresh diffs for me to pick through. Our stack has a lot of breadth and I find myself reviewing anything from JavaScript (Node.js and browser) to C++ to PHP. We've got Angular and React (both TypeScript), as well as some crazy legacy stuff.

I'll perform some default coding work here also — tackling a ticket, merging branches, and a dash of technical writing.

#### 9:30am

People slowly arrive until our scrum standup meeting. I'm normally there first, I obsessively carry around a pen and post-it notes, a habit from when I was new and didn't want to forget anything. At scrum meetings, you say what you did yesterday, if anything is blocking you, and what you will be doing that day. Our 'scrum master' will direct or correct people as needed. It's a fun, relaxed atmosphere. As well as coders, there will sometimes be product management, technical writers, and support staff.

On average, I have about 0.5 meetings a day. These can be design meetings, catch-ups, [sprint](https://en.wikipedia.org/wiki/Scrum_Sprint)-related, or general company events. For the rest of the time, I'm coding by myself and helping or being helped by those around me. Sometimes we'll do some pair-programming when we think it will be beneficial. We all have a lot of autonomy. We work hard to get things done in time for the end of the sprint but if they don't get done then that's fine too, resources will be reallocated, no one gets in trouble for missing deadlines as long as they're open about it. In fact, I can't remember anyone getting in trouble for anything.

#### 12pm

Although we have semi-flexible working hours, the whole company takes lunch at 12 for an hour. Some people take a shorter lunch to get home earlier. I'll take the first 15 minutes to have a snack, call my fianceé, and stretch my legs. For the remaining 45 minutes, I will study or write. I use this time to read documentation or create 'hello world' applications in new tech stacks. I do tutorials, read technical blog posts, and take coding challenges. If I'm writing, I do it longhand with a biro in a A4 lined pad. All of this takes me out of my own head. My lunchtimes feel long and relaxing.

#### 1pm

For the rest of the day, I continue with default work. At around 3pm, it's clear that everyone's most productive hours are over. People don't work slower on purpose, it just seems to happen. We manage this by doing non-intensive but still time-consuming work. Testing applications, writing documentation, taking non-essential meetings.

#### 4:30pm

My day is over. I commit to any branches I have open, even if it's just to say "End of day commit. I'm mid-way through building X". I play games with some of my deskmates so it won't be the last time that I speak to them that day. I wipe the rain off my bike's seat and cycle home. I have to go through a wind-valley, so it often feels like three-times the distance. I've been slowed down to walking speed before.

#### 5:30pm

After eating dinner with my fianceé and catching a show, I'll load up one of my projects and start developing. I've been tinkering around with my website recently. That's my guilty pleasure because it's never "productive" or at least it doesn't feel like it. The things that give me an endorphin rush are coding, writing, and designing. I like testing too, surprisingly, but I build my web applications to be testable from the get-go. If there's a longhand blog to write up I'll try and get it out of the way early so there can be some time between finishing it and editing it. My undergrad was in Creative Writing so writing technical blog posts is probably the easiest part of my day. It's an amalgamation of the two things I love most.

#### 8pm

I'll take a break at eight for some video games unless I'm pushing to complete a personal task. My main game at the moment is Overwatch on PC. I will still feel a swirling of ideas and code-flow-structures as I play but I suppose it's at this point that I start to "unwind" but not that it feels like there's anything to unwind from.

After playing games, I'll edit blog posts, and add small things to my projects — most of the good ones I open source on [github.com/healeycodes](https://github.com/healeycodes). By adding small things, I mean refactoring small functions, adding some UI flair. I make sure not to start anything major in the evening. I will sometimes do a tutorial if I feel like the day has been unproductive — I'll choose an area of compsci that I don't normally touch, for fun.

In the evenings, I like to read. Lately, I've been reading [Grokking Algorithms](https://www.manning.com/books/grokking-algorithms) which is a very accessible but still in-depth book on algorithms and data structures. As far as fiction goes, I've been reading Ben Lerner as well. I work out, shower, and hit the hay.

#### Weekends

I try and complete a small project end-to-end every weekend. This last weekend, it was [Project Mood](https://github.com/healeycodes/project-mood).

<br>

#### Backmatter

Recently, I've joined Twitter to become more of a part of the developer community (I want to give back!) — I'm at [@healeycodes](https://twitter.com/healeycodes). I'm also looking for fun open source projects (big, small, or tiny). Feel free to reach out.

🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴🚴

Living, working, building, and drinking too much coffee.

A Day in the Life of a Mediumly Productive Software Engineer


#### Code review is the best part of the job

I went from being afraid of being judged to embracing team-spirit. Today, I find myself completing a ticket and looking forward to placing it in review. I really enjoy the feedback I receive from my peers and the conversations that start as a result. It's a great chance to learn more about the project's architecture and patterns. In a past life, I was a Creative Writing student so I understand that editing something *always* makes it better.

I like giving as much as getting. I was encouraged from day one to join in the review process. I understand how to optimize JavaScript quite well so the first comments I made were offering advice for the performance critical parts of the code base that came through review — all of which were well received.

Software engineering as a field has so much breadth that even people starting out in the industry have something to offer a team. Whether they read a tech blog, built a project in the stack, or went deep in the documentation.

#### Coding is one of the least important parts of the job

Don't get me wrong, if I start slinging bad code into review, I'm going to run into issues. However, I've found that the most important skill at my job is communication. I need to understand what my project manager is telling me so that I can translate it into code. I need to then listen to my manager's feedback about my approach. If I can't explain my design to my teammates then it will take them longer to understand my (hopefully self-documenting) code.

I was part of a group of three designing a new module when I realised how my communication has grown. Much like the ideal piece of code, the best way to communicate is with simple, almost boring language — all backed by the correct abstraction. Figuring out the exact requirements, and the right tools and modules avaliable to you is 85% of the battle in completing a ticket.

```javascript
/* Boring vs. Fancy.
 *
 * Task: Given a one or two digit Number, zero-pad values below ten
 */

// Fancy - uses String-tricks
('0' + foo).slice(-2);

// Plain old logic - significantly faster!
(foo < 10) ? ('0' + foo) : foo;

// ES7 gives us a native pad operator but it's not optimized for this situation either
foo + ''.padStart(1, 0);
```

I tackled a high-priority bug — something that crippled our product — I dug for a whole work day in order to find the one character, a single byte, that needed to be removed in order to fix the whole thing. That was a good day. Other weeks, I blast out boilerplate like they're paying me one penny a word.

<br>

The worst part about my job? The winter weather commute!


Career posts