DEV Community: Paul Hallett

I'm Paul Hallett, and I support women devs.

Paul Hallett — Tue, 03 Mar 2020 20:40:51 +0000

Equality in tech looks like…

A progressive and beautiful world.

Equality should mean all people, of all genders, religions, and beliefs, all contribute and gain equally from working together in technology.

Not just from being a developer in a team, but also equal gain from the products that are built with technology.

I will advocate for equality by…

continuing to highlight the work done by lesser represented people within my team and within the technology community.

I will continue to offer mentoring and support to lesser represented people who deserve equal opportunity in tech.

My advice for fellow allies to support self-identifying women and non-binary folks who code is...

Treat people with compassion. We are human, and we all make mistakes.

Find opportunities to give lesser represented people a chance to build something new, or learn something new, and coach them through it. Encourage and show them that they are capable.

Highlight their successes and their efforts, and give them a high five when they succeed!

I built a popular open source API project, Ask Me Anything!

Paul Hallett — Wed, 19 Feb 2020 22:54:44 +0000

I recently blogged about how I built PokeAPI, a very popular open source API. A lot of new developers often encounter this early on in their career.

I want to give people a chance to ask me questions about it, or about running open source projects, or programming in python/django.

So...AMA?

Be comfortable with being uncomfortable

Paul Hallett — Wed, 19 Feb 2020 22:52:15 +0000

One piece of advise I often give to new developers or people who find it difficult to accept they don't know everything:

be comfortable with being uncomfortable

I have been programming for over eight years now, I've given tech talks and built open source projects, and I've been a tech lead for two years.

I regularly, almost daily, do not know how to immediately solve the tasks I am given. Over the years I have learned tricks to help me discover a path to a solution, but I rarely have a solution jump up straight away.

This is a common situation for programmers: we are problem solvers. We don't just write lines of code. Problems are problems because they don't have easy solutions.

So when you're faced with a problem and you have no idea where to start remember: that's okay, it's part of your role. You will figure it out.

Get comfortable with being uncomfortable. Every time you learn a new technique to help you problem solve: remember it, and use it when you encounter a new problem.

A retrospective on PokeAPI

Paul Hallett — Tue, 18 Feb 2020 01:15:15 +0000

About seven years ago I created pokeapi.co. This is the story of how I built it.

It is always a delight to hear people talk about PokeAPI and how they use it. Sometimes, I don't even mention I built it to those people. I just like seeing how much joy it brings them, and how much they learn from using it. It is a feeling I can't quite describe. I feel like the creation of the site involved a short amount of very intense effort that turned into my most successful thing ever. So it's not like I did anything nobody else could, I just did it first.

And to top it all off, it's about...Pokemon?!

I had graduated university in early 2013. At university I had built a few simple Pokemon battling simulators as I was learning to code. The way the Pokemon video games worked made a lot of sense to me, from a "programming" perspective. It's all about numbers and structured data. I was already a keen Pokemon fan (obviously) and at one point I was even in the top 16 Pokemon trading card game players in the UK. I had even taken the Professor course and judged at competitions.

In 2013, APIs were just beginning to become valuable products, with startups like Twilio and Stripe being the new hotness of the early decade. After I graduated I moved to London to work with a company I had interned at the previous summer. The part of programming that captured my attention was the philosophy behind REST APIs but I didn't see many APIs following this pattern.

So I took the idea of a pure REST API, and then I took the data that was scraped from the games and I built a REST API for it.

The project took me literally one weekend to complete. I sat in this costa coffee shop and bought about ten coffees over two days, stole their wifi, and wrote the entire project. That was all it took.

I created a twitter account for it and shared the project on hackernews and boom I got 2,000 hits in less than a day.

Depression

Let's jump into a side story quickly because I think it is important. I've struggled with mental health since around the time I built PokeAPI. In fact: the reason I was so focussed and hammered it out is because I was in a major depressive peroid and desperately needed some distraction. I had no friends in London, I was running out of money, and I no family there to help me.

I have to deal with mental health every day, and it's hard for me to understand how I produced something like PokeAPI when I was in one of the darkest periods of my mental health journey. But it is what it is, and for the record: I am managing my mental health very well now.

PokeAPI v1

The original version was a debug-mode (yes, I left it in debug mode for about a year) Django project running Tasty pie to expose the data through an HTTP API. It was really janky, it barely held together. I coded the frontend using very basic JavaScript knowledge (I didn't become a proper js developer for at least another five years) and some poor css.

But that didn't matter because it became popular really fast. It even landed me my first real job, where I got to travel around the world and promote APIs. I was incredibly lucky and at the time I had no idea how I had pulled it all off.

PokeAPI v2

Around 2015 the API had served roughly a million requests. I figured out this number by logging each hit in a database table for each month. I would then print out that table in csv format, copy & paste it into a spreadsheet, and then do some excel math to sum the values.

The site was still very janky, but at least I had turned off debug mode by this point. A developer called zaneadix came along and wanted to extend the API to support all the data in the veekun data set. I told them I was happy to let them contribute, and they did, incredibly so. This version was built on the same project but it used Django REST Framework to provide the APIs.

We released v2 of the API around June 2015. The most contribution I did at this point was code review and bug fixing. V2 was a huge success, and I think we hit 25 million API requests about a year later.

Moving towards static sites

So by 2018 I was barely involved in PokeAPI. There was occasional bug fixes and data updates, but a team of people were now managing it all for me, without me asking. Alessandro and Tim became, for all intents and purposes, the core developers of PokeAPI.

At this time I didn't contribute much, and I let the project run stale. I had more important things in life to deal with. I think it's okay to step back from stuff like this. But I could have been more open about it.

The team wanted to help me reduce the cost of the site. It was costing me around $40USD a month to run, purely because it was unoptimised and running on one giant machine on DigitalOcean.

Alessandro and Tim came up with a tool that scraped the site, generated json files, and then hosted them on a server. The frontpage and docs became a separate repo too. This reduced the costs to less than $10USD a month. I maintained the cost for the domain, which was around $30USD a year.

and now

So here we are, in 2020. The project is as strong as ever. We provide about 23 million API requests a month. That's an insane number. It is used for teaching API development all over the world. I see it mentioned in all sorts of blog posts, official documentation examples, and even video game articles.

Here are just a few more articles talking about it.

What more is there to do? It needs new data. It is about a game and a half behind the current series. There are something like 1000 Pokemon now.

It could benefit from some new features. But that would increase the costs. I don't think it will ever be a full time job, because the lawyers will come running at me.

Side note: I met some developers from the Pokemon company, and they love my API. They were keen to collaborate, and I tried to pursue something but it never went anywhere. Their loss, I guess.

I am thinking of coming back to build new stuff. I know it's an excellent resource for learning, and I want to tidy up the source code and use it to show off good open source practices, not just a good API resource for learning.

Also: people keep asking for a search feature. This would not be in the production version, to keep costs down. But it would be easy to add to the open source project. So maybe. Watch this space.

Retrospective

What would I share about this story? Let's do an open retrospective to talk about the good and bad.

Bad

What has gone wrong with this project?

I should stop avoiding issues on the project and address them.
I have not shown enough appreciation for those who helped to keep it alive when I was absent.
Building things are really easy, working with people is hard.
I used to treat every comment as personal criticism. I felt obligated to deal with all issues. That's not okay, and I shouldn't have to.

Good

What has gone well?

It only took a short amount of very intense effort to get this started. My advice to anyone who wants to build something: you can do it! Just try!
It has inspired probably hundreds of people to program. I genuinely wonder how many people have been introduced to programming because of me and the rest of the team. That feeling is just bliss.
It has helped me with my career. Some people say you should run a side project because it will show off what you can do. PokeAPI literally scored me multiple jobs, so that advice was true for me.
I ended up discovering a framework (Django) that I love. I went on to help with it and ended up becoming a Django foundation member.

Parting advice

PokeAPI didn't take me long to build, and it was only a short, intense burst of effort. But I was also very very lucky. Don't feel disheartened if you can't find a niche thing to build. But do keep building stuff - you never know where it might take you. There are hundreds of franchises or things out there that could do with an API; so build one!

Lean retrospectives for developers

Paul Hallett — Fri, 14 Feb 2020 00:35:38 +0000

They same time is money, but I hate that way of thinking. I think "Time is valuable" is a better saying. Getting the most out of people's time is important, especially when it is hard to get everyone into a room together.

I see a lot of people running retrospectives, and I see them resulting in very little value; just an opportunity to vent or raise issues. The lack of value comes from the fact that almost no time is given to creating actionable items out of a retrospective. People like to have their voice heard, but they value actions and results from being heard more. If it carries on without action, your retrospectives will no longer be valuable, and people will stop attending.

So if you're running a retrospective, how do you maximise the amount of value without having to learn the secret sauce of managing them effectively?

So here is how I run retrospectives, based off me running about 100 or so, and the experiences I've had with them.

I've found the best thiing is maximise the amount of time discussing issues and creating actions. Those actions can then be followed up, and most importantly: addressed at the start of the next retrospective.

You should be able to fit this into an hour comfortably.

Step by step

There are three phases to my retrospectives:

Address previous action items
Gather ideas
Discuss ideas and write actions

First things first

Take one minute to remind everyone that retrospectives are a safe space to critically discuss issues. This is not a blame game, and if you really want to, remind everyone of the Retrospective prime directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

Address previous action items

5 minutes

Go through the list of action items you created last time. Explain what steps were taken to complete the action. If the action wasn't completed: ask if it is still important. If it is not important: drop it. If it is: add it to new Action list. If an action keeps being ignored, you have an issue that needs to be addressed outside of the retrospective.

Gather ideas

5 minutes

Ask people to write down their ideas on post-its. You can use whatever retro format you like. I prefer start, stop, continue.

After 3 minutes, ask people to start coming up and placing the tickets on a whiteboard or wall. People do not have to voice their opinion on their ticket yet. People can keep writing tickets until the five minutes is over.

As facilitator; I like to start grouping tickets into topics during this time. Chances are people have similar feelings about the positive and negative things happening in the team. The only section that will be different is the ideas section.

Discuss ideas and write actions

50 minutes

This section is where the value of retrospectives is hidden. So I try to maximise the time spent here.

For each topic; summarise it to everyone. Chances are you are aware of the topic, so you can give some extra context if you like. Do not ask people for their voice or opinion on each topic yet.

Once summarised, start with the negative section (like stop). People often pick the positive topics to discuss first, I think it is best to leave that section to the end. For each topic, summarise what people are feeling. Ask the group: "Does anyone having anything more to add"?

Now is the time to start discussing this topic. As a facilitator: I try to find opportunities for actions that can help solve the issue in this topic. Propose ideas to the group or encourage people to suggest ideas.

I find if I spend more than five minutes discussing a topic then it usually won't get much further. So as a facilitator I try to reach a decision on an action in five minutes. If people feel like more time is needed for that topic: then the action can be "Have a longer discussion about topic X before the next retro".

Once the negatives are out of the way, start discussing the ideas. Usually one person will suggest one idea, so encourage them to explain their idea more. I find that the actions from this section usually result in someone trying out the idea and reporting back to the team before the next retrospective.

Finally, I summarise the good points. This section is usually around team wins, production deployments, feature launches, or other successes. They're a great way to end a retrospective and they usually don't have actions.

Wrap up

To wrap up the retrospective, I summarise the actions that are to be taken. I will try and assign each action to a person. Shared responsibility is good, and there is a higher chance actions will be completed. I usually take a photo of the post-its or write them down, and send around an email summarising the whole meeting. This email becomes the list you read from at the next retrospective about what actions you had previously.

Easy

There you have it: my lean retrospective without any magic or fluff. It's straight to the point and designed to maximise the time. Feel free to copy and paste this idea fully, or take the parts that you find valuable.

What is the deepest number of ssh tunnels you have gone to?

Paul Hallett — Thu, 16 Jan 2020 01:50:09 +0000

At work, to do any manual inspection in the "backend" server for one of my projects I have to ssh into the "frontend" server first.

home~$: ssh -A paul@frontend
frontend~$: ssh backend
backend~$: |

This is only two layers deep, but it made me wonder how far people have had to go in their day-to-day work in order to work with their projects.

So, what's the deepest number of ssh tunnels you have gone up to? Why did you have to do it?

What are the biggest barriers to writing tests in your project?

Paul Hallett — Wed, 18 Dec 2019 01:44:30 +0000

Does your team struggle to write tests? If so, why?

How do you deal with blame culture in your team?

Paul Hallett — Wed, 18 Dec 2019 01:43:25 +0000

This boils down to code ownership, somewhat (IMO).

Do you work in a team where everyone owns everything, and shares the work / problems / issues together?

Or do you work somewhere with a "you change it you own it" culture?

What is working well for your team, and what isn't?

Help me design better Django applications

Paul Hallett — Tue, 17 Dec 2019 23:00:22 +0000

I've been building a set of pragmatic guidelines around Django for the past year. it's based off the experiences I've had scaling Django applications. It takes an API-first approach to ensure developer productivity and flexibility is kept high.

I want to get feedback on it.

I've had a few people use the guidelines, and by using them myself I have iterated on it a few times. We've had four versions so far.

But I know it can be better.

So if you use Django, or you're interested in Domain Driven Design, please give it a read, or maybe even try adopt the pattern yourself.

Throw some opinions at me here or on github, and let's aim to make API-based Django applications better, for everyone!

-> https://github.com/phalt/django-api-domains <-

Do these three things when you start a new developer job

Paul Hallett — Tue, 17 Dec 2019 21:24:31 +0000

I have worked at quite a few places now. Each time I have started a new job, I have found it difficult to get myself into "full productivity mode". With each job I started, I figured out a new thing I can do to help me reduce the on-boarding time.

In my new role, which I started in November 2019, I did some preparation. I picked three things that helped me get up to speed in the past. I would try and do these within the first two weeks of my new job.

I won't focus on the admin tasks like sorting out HR, or setting up your developer machine, or getting access to various tools your team uses. These things should be helping you become productive and valuable quickly.

Grab time with each team member

Getting to know your team members is a great way to understand who they are, how they work, and what they do.

In your first few days, you might get assigned a buddy. They will try to introduce you to the people who matter most for your role. This usually goes by in a flurry and you are likely to forget their names. When you start writing or reviewing code, you will likely be nervous about offending them. This is all normal. But you can reduce the amount of time you feel awkward by having one-to-ones first.

That's why I recommend scheduling informal one-to-ones with each team member, spread out across your first two weeks.

Goals:

Get to know what each team member does.
Ask them how long they have worked at the company.
Ask them what is going well on the project.
Ask them what can improve.
Get to know who they are as a person (if you feel comfortable talking about that).

Grasping the situation like this helps you understand the state of the project. It also helps you to understand who the humans are around you. We're all interesting characters and no two people are the same.

This will also set you up to understand how you can be effective in the team. Perhaps there is an issue that keeps coming up that you can help to solve? Someone might ask you about a skill that you're good at and if you can help them learn it.

In my experience, I learned from three separate catch ups that we wanted to improve our testing. I shared some of my past experiences around this subject. We agreed that one of my first goals would be to help the team skill-up writing software tests.

Understand the project domain

Every new role comes with a brand new project and problem. If you are lucky, the project will be well documented, with some diagrams about how it works. There may even be a wiki describing how the problem is being solved by your software and what value it provides to users.

Even if these type of documents exist, sitting down and understanding the domain of the project is a valuable exercise.

I recommend grabbing another developer and drawing an entity relationship diagram on a whiteboard in your first few days.

Remember: you are not drawing a database structure, you are drawing a domain diagram. It should focus on the application logic. It should be understandable by non-technical members of your team. Here is an explanation if you're stuck.

Goals:

You should use this time to ask questions. Make no assumptions about how things work.
Understand the high-level domain of the system.
Learn how the system achieves the user requirements.

After you have drawn a domain diagram, if one does not already exist, now is a good time to take a picture and stick it in your wiki or docs. It will be helpful for future team members.

In my experience, I spent an hour learning about one of the projects I am working on. I challenged my own assumptions and helped to understand the state of the project. I even ran it by a second team member to confirm my understanding was correct.

Complete a small programming task

Some blog posts have recommended this one point: ship some code on your first day. I guess the intention is to help you understand the procedure for shipping code. Learning how the team tests, reviews code, and ships it is definitely valuable. But I don't think it needs to be the absolute first thing you do.

I recommend taking on a small programming task in your first week.

The task should not be a bug fix. It should be a minor feature that you can finish in about a day of work (excluding environment set up time). You should be writing some tests and learning the review process by doing this.

If you can find a team member who is free, you can even try pair programming on this task.

Goals

Understand how the software is designed.
Understand the process for writing tests.
Understand how you make a pull request and merge your code.
Understand what "done" means for a feature ticket.

In my experience, I had to change a date time picker to display the last 2 years only. It was a simple enough change and I learned about the framework and how our CI/CD pipeline worked by doing it.

Remember: starting is slow

Let me wrap up by saying: starting a new job feels slow. You are likely used to high productivity from your previous job. This will feel like running through mud. That is a totally normal feeling.

Learn how your new software works.

Learn how your new team works.

Start contributing value, not just through writing code but by figuring out how you can work with your team members too.