How to do Coding Peer Reviews with Github

In my current contract, we do coding peer reviews. When I was first introduced to this process, I was a bit sceptical. Mostly, I thought it was a huge time-suck and an overly-laborious way to fix bugs.

After several months of going through the coding peer review process, I can say I’m a convert. Anything that improves the quality of code and simultaneously enables a team of coders to give feedback and learn from each other, is a good thing.

In this video, I go through some of the main benefits of the coding peer review process, as well as demo-ing how to do coding peer reviews with Github.

Biggest Developer Frustrations Reported By You (Q&A)

As part of our weekly monthly newsletter, we send a survey out to all of our readers. A small percentage of our readership respond, but their answers are always telling.

One of the questions we ask is: What is your biggest frustration?

The top 5 answers are:

  1. Not having enough time
  2. Finding work as a developer
  3. Too many technologies to learn / fast-pace of technology
  4. Finding bugs
  5. Coming up with ideas

I address how I personally cope with all these frustrations in the following video. If you have any of your own personal tips or techniques, I’d love to hear them.

Read more

My experience with Dell Support (Dell Hell 2.0)

As a software engineer, the most important tool you will ever need for your job is your computer.

In January 2015 I decided it was time to get a new laptop.

I was currently using an Acer Aspire V3-571 which lasted me a good year (which was impressive considering it only cost about £500) but eventually it started to slow down and became difficult to work with.

I decided it was time to invest in a professional grade laptop with good support. I wanted something that was lightweight, powerful and reliable.

I spent a considerable amount of time researching the different products on the market and finally landed on the Dell XPS 15. Here’s why:

Read more

Attitude vs Experience: What’s more important for developers?

When I was looking for my first software development job, I kept hearing the same thing: “you don’t have enough commercial experience for this role”…

I kept persisting and eventually I got a job at a startup, where I worked for two years.

When I decided to go freelance I was surprised that, after having two years experience as a developer (which in my eyes is a like a century in the fast-changing technology world), I was still hearing the same thing: “you don’t have enough experience for this role…”

But I kept on trying. I worked on my own projects. I published them online. I kept reading and learning new things…

After a few months I got my first freelance contract working with Python.
Read more

How to ask questions on Stack Overflow (and get answers)

A lot of people ask me questions when something isn’t working.

While I’m more than happy to help where I can, the questions I tend to get don’t outline enough information for me to be able to answer them. But more importantly, I might not be the best-suited developer to help.

Which is why every programmer should learn how to ask questions properly on Stack Overflow — to get the answers that they’re looking for.

Read more

It doesn’t bloody work! 4 things to keep in mind when reporting a bug

Picture of a ladybug

As a professional software engineer, I deal with bug reports all the time. As a result, I have had my fair share of tickets which read something along the lines of: “<insert arbitrary feature here> is not working!!!”.

Don’t get me wrong, I am a strong believer in Kaizen (Japanese for a “system of continuous improvement”) and as a result, I love getting bug reports. They create a great opportunity to fix something in the software which may have otherwise gone unnoticed or turned a user away from out software. I do however, also believe that a lot of time could be saved if bugs are reported properly, so here are some tips on how to report bugs:

1. Take screenshots

A picture paints a thousand words. Where possible, always provide a screenshot of the error message or problem you have. These are very helpful when debugging an issue because the developer can get see exactly what the error looked like when it appeared.

2. Describe the steps

List the steps you took before you saw the bug, in a number list. This might look like this:

  1. Logged into the app
  2. Selected messages on the right
  3. Opened my latest message
  4. The app crashed

3. Give specifics

Assume that everything is relevant. Be as specific as possible when describing the issue. Provide details such as:

  • The username of the account you were logged in as
  • Operating system/device you were using
  • The time the bug appeared
  • The last screen you saw before the bug happened
  • Any error code (developers LOVE error codes)
  • What you ate for dinner

The more specific the information you give the more the developer has to work with.

4. Include only one problem per ticket

If you have noticed more than one bug, it might be tempting to bundle them all into the same ticket. The problem with this is that an engineer will likely add specific notes relating to a bug to the ticket as they are debugging the issue. This is so if a bug is assigned to a colleague, they can easily pick up where the previous engineer left off. This can become confusing if a ticket is referring to multiple different bugs.

Do the above and your bug will likely be identified and fixed much faster by the development team.



Ladybird photo by Alfie Ianni: