There's a lot of confusion around the differences between services like Tailscale and ZeroTier (VPN's), and services like NordVPN or Mullvad (Proxies). While these two types of services both technically use VPN technology, they accomplish very different things.

This is a topic people seem to trip over all the time, and it's really unfortunate that proxies have decided to go with the "VPN" language. I will admit, they do use a VPN under the hood, but the the actual functionality they offer is really just proxying traffic.

Virtual Private Networks

A VPN is a Virtual Private Network. The original use case, and still very much in use, is to create some sort of private network sitting on top of another physical network. The clearest cast for this is the Corporate VPN. You setup a Virtual Private Network ontop of the internet using a tool like Wireguard or OpenVPN. The Corporate VPN lets a remote device connect to one in the physical office, or maybe some cloud server running in AWS or what have you. This VPN service requires you to have a certificate or credentials provided by the corporation. It can give three things, depending on the needs and configuration:

1. Authentication that identifies you as an employee of the company
2. Authorisation which will determine what you can access
3. Encrypted data transport which lets data be transported over physical networks like the internet without being readable by others.

As a minor implementation note, many of these kinds of VPN's will only put traffic destined for the private network over the VPN transport. This makes the load on the VPN lower. It basically means your traffic destined for netflix goes over your normal non-VPN connection, but your traffic for database access to an internal application goes via the VPN tunnel.

Tailscale is this, with a beautiful interface (both command line, and web wise) and some additional features built on top, such as MagicDNS. Tailscale uses Wireguard under the hood which is an open source VPN tunnel which you could use on it's own if you wished.

Proxies

NordVPN, Mullvad, and all the others are more like traffic proxies, which use VPN technology. The goal here isn't to provide secure access to private resources, if you tried to do this you'd more likely open security flaws in your system than anything. Instead you're joining a VPN with loads of other users from around the world. Typically these VPN's take all of your traffic and send it through their servers, before it then exits to the wider world.

When you have thousands of random people from across the globe accessing services via a cluster of VPN exit points, you get the potential for anonyminity (huge asteriks here). In this case your ISP sees you're sending encrypted packets (via something like wireguard) to an IP address and nothing else. They don't know what the traffic is though because the destination is just one of the VPN's entry points, not a server with an IP owned by netflix.com.

On top of this, these proxies can then choose where your traffic exists. This gives you the fabled ability to "appear from anywhere in the globe", and access content that's region locked.

NordVPN and Mullvad are there to help you blend into the crowd, and appear as if your data is coming from somewhere you're not. It's very much a privacy tool, at least from your ISP. Netflix still know how you are, because you're logged in with an email and password. The VPN also knows who you are because you're logged into them, and they know what you're accessing because you're sending data via them for netflix. HTTPS and DoH both help you a bit here, but it's not perfect and outside the scope of this already massive response.

What about Tailscale's "Exit Node" feature?

Tailscale has an exit-node functionality. This is brilliant if you need to have all your traffic appear as if it's coming from a device you own. An example would be if you're travelling to a country your bank block access from. If you've setup an exit node before hand, you can proxy your traffic over your tailscale network and have it exit at, for example, your home desktop. Now your bank think you're accessing your account from home, even though you're in another country. But this exit node is a private one for you, it does not give you any ability to "blend into the crowd". It also doesn't hide traffic from your ISP if your exit node is at home of course.

In summary...

Tailscale is a VPN, but very much focused on giving you a private network of your own. Mullvad, NordVPN and co are also VPN's, but you're joing a giant network with the aim of becoming somewhat anonymous to outside eyes (again, huge asterisks here).

Both have their uses, they do overlap to some degree, and Tailscale even lets you use Mullvad as an exit node to get all of the above at once. But that said, you may not always want or need them all.

The Ghost 5 upgrade is quite significant as it requires the use of MySQL 8 where as I was still using MySQL 5 🙈. I posted briefly about my approach on this GitHub Issue but figured it may be useful to go into more detail for anyone who wants a bit more explanation.

Starting state

My starting state was pretty simple, I was running Ghost 4.44 and MySQL 5. I was also using file mounts for my data storage, however this guide should work just fine if you're using volumes.

version: '3.7'

services:

  ghost:
    image: ghost:4.44-alpine
    restart: always
    depends_on:
      - db
    ports:
      - "127.0.0.1:3400:2368"
    volumes:
      - ./content:/var/lib/ghost/content
      - ./config.json:/var/lib/ghost/config.production.json
    env_file:
      - ./db.env

  db:
    image: mysql:5
    restart: always
    volumes:
      - ./data:/var/lib/mysql
    env_file:
      - ./db.env

Step 1 - Take a full backup

I'm going to be changing database versions as well as a major upgrade of the ghost application. Given the scale of those changes it would be silly to go any further without a full backup. How you do this is up to you and will depend a little on your setup, here are a few approaches.

First, take an export from the ghost admin interface. This won't be perfect as it doesn't export any media but it will give you post content, tags, pages, users, and newsletter members. It's so quick and easy to do, I'd recommend doing this anyway.

Second is a database dump. I have been using a mounted directory for the MySQL data, but none the less I ran a full database dump rather than taking a copy of that directory. Having the raw SQL felt like a safer approach for me, this also has the benefit of working nicely if you're using volumes as well which I'll likely move to in the future. Here's an example command for you to tailor to your needs.

# The following will execute the mysqldump command on your MySQL container. Make sure to adjust the MYSQL_PWD, container name, and database name to fit your needs. If you've got those right you'll get a file called `db_dump.sql`.

$ docker exec -e MYSQL_PWD=root_password_here -i container_name_here mysqldump -u'root' --databases ghost_prod --skip-comments 1> db_dump.sql

Finally, take a backup of your media and theme as well if appropriate. My media was stored locally with a file mount so the process for this was just copying and zipping the directory. If you're using something like S3 your approach will differ. This upgrade shouldn't touch the media files as far as I can tell, but it's a good idea to make sure your backup is complete in case something does go wrong for you.

Step 2 - Upgrade your MySQL version

If you're already on MySQL 8+, you can skip this step. I was on MySQL 5 though so I had to go through this step as well and I suspect many others will also.

In this step you're going to want to replace your mysql version in your docker-compose.yml with mysql:8. In my case I used mysql:8.0.29 to pin to a specific version, you may wish to do so too but I'd suggest using the latest of the 8.0 release on dockerhub.

Once I'd made that change, you then need to tear down the compose containers and bring them back up to ensure the new mysql version is used. Here's a command for doing that and jumping you into the logs straight after:

# Take down the compose containers, bring them back up, and follow the logs.

$ docker-compose down \
  && docker-compose up -d \
  && docker-compose logs -f

If all goes well you should end up with your old MySQL container getting removed and a new MySQL 8 container replacing it. Once everything has had a chance to process and you're seeing the logs, check your blog. Have a click around, login, view some posts and make sure everything is ok. If it's not then this may be the time to look at restoring from your SQL backup. For me this process went just fine and MySQL seemed to handle it's upgrade pretty quietly and without a fuss.

If you need to restore from your SQL backup at this point, here's a command you can tailor to your needs. You'll need to run this from a blank slate though so you will need to delete the volume or file mount and re-run the commands above to get to that state. I'd recommend doing so with your ghost container commented out temporarily but your needs may vary here.

# Execute a command on the MySQL container (container_name_here) using your root mysql password. The mysql command will read input from the db_dump.sql file and execute those MySQL commands. You may need to start from a blank slate for this to work properly.

$ docker exec -e MYSQL_PWD=root_password_here -i container_name_here mysql -u'root' < db_dump.sql

Once you're using MySQL 8 successfully and your blog content is all there, you're ready to upgrade Ghost itself.

Step 3 - Get to the latest version of Ghost 4

The Ghost team only support major version updates from the latest version of your current major. That means you need to upgrade to 4.48.5 before you try and upgrade to 5.

To do this you'll need to change your ghost version tag to ghost:4.48.5 and run the same command to tear down and re-run the compose containers.

# Take down the compose containers, bring them back up, and follow the logs.

$ docker-compose down \
  && docker-compose up -d \
  && docker-compose logs -f

It is important to do this restarting step, as ghost will need to run any remaining database migrations before the major version jump. If you do not do this part, you're effectively skipping this step and will be outside the version upgrade support path.

Once again, check your blog is in working order after doing this. I performed an upgrade from 4.44 up to 4.48 which wasn't a big jump, if your jump is larger your mileage may vary. Ghost do maintain the upgrade path jumping up minor versions so you shouldn't need to go from 4.44 to 4.45 to 4.46 etc.

Step 4 - Upgrading to Ghost 5

Now you're on MySQL 8, and the latest Ghost 4 version you're ready to upgrade to Ghost 5. I made the jump straight from 4.48.5 to 5.0.2, you should be able to go to the latest version of 5 without any problems but if you're nervous you may choose to go to 5.0.2 and then upgrade again to the latest version of 5. This should be unnecessary, but I've not tested from 4.48.5 to 5.47.0 (the latest at the time of writing).

The process is much the same as Step 3, update your ghost version tag and reboot the compose containers.

For me that was setting the ghost image tag to ghost:5.0.2 and running the same command we've run a few times already.

# Take down the compose containers, bring them back up, and follow the logs.

$ docker-compose down \
  && docker-compose up -d \
  && docker-compose logs -f

Check your blog once last time and make sure everything is as you'd expect. You'll more than likely need to make changes to your theme, be that an upgrade or changing the theme yourself. For that you can follow the guides on the official ghost documentation.

End result

My final docker-compose.yml file ended up looking like the following. Your ports and volume mounts will differ depending on how you configured your instance originally.

version: '3.7'

services:

  ghost:
    image: ghost:5.0.2-alpine
    restart: always
    depends_on:
      - db
    ports:
      - "127.0.0.1:3400:2368"
    volumes:
      - ./content:/var/lib/ghost/content
      - ./config.json:/var/lib/ghost/config.production.json
    env_file:
      - ./db.env

  db:
    image: mysql:8.0.29
    restart: always
    volumes:
      - ./data:/var/lib/mysql
    env_file:
      - ./db.env

Back in my final year of University I was one of the first GitHub Campus Experts. Last week I joined Juan Pa on the weekly GitHub Education live stream to catch up with him and the current campus experts. We took questions from the current community of experts and talked through our experience and advice around those topics. Over the next couple of weeks I'll be taking some of those questions and diving deeper into them.

This week we're going to look at one of the questions Juan asked which peaked my interest in particular.

One of the biggest constraints we've seen students experience is time management. You need time to build a community, create your own side projects, and also go through college and graduate. How did you manage everything that you did? I know you learned a lot of your stuff on your.

https://www.twitch.tv/videos/960144777?t=00h44m50s

Time management is something I've personally struggled with massively, and continue to every day. It's specifically something that was called out by a lot of my school teachers along side other areas of my dyslexia.

I'm not one for heavy process and I struggle to stick to cumbersome systems, so my time management approach is pretty simple. You can listen to the VOD above for a brief overview first if you like, and then come back for more detail.

Priorities

I learned pretty early on in my career that the root of a lot of time management issues come from unclear priorities. That's true both in work, and in life.

Unclear priorities show themselves in tons of different ways. For me, it usually results in either faffing around doing nothing of any value, getting stressed because I'm doing too many things at once. This is comes from my mind not knowing what I should be doing, so it either struggles to do everything or gets stuck and does nothing.

Having a clearly defined and well ordered set of priorities solves the question of "what should I spend time on?"

You will probably know your priorities at home, but do you know what your piorities are at work or university?

However you manager your work vs life separation, you need to ensure you can always answer the question of "what is my top priority right now?" This may shift during the day, week, month, and year but you need to be aware of it.

In a software team the priorities are often set by the Product Manager or Engineering Manager. If you're stuck wondering what your focus should be, ask them! They should give you an answer that aligns you quickly with the team, and with the business. If you're in college / unviersity then the question is probably one for you to answer by reviewing your grades and what your current grade predictions are.

Your time is your own, and everyone is going to want some of it. Only you get to choose if they get that time.

Defend your time

Now that you know what your priorities are, it's up to you to ensure you have ample time to work on them. Here's something people won't tell.

Your time is your own, and everyone is going to want some of it. Only you get to choose if they get that time. What's more, there are only 24 hours in a day, and probably only 6-8 where you'll have the energy to use them well.

To get work done you need time, and the only way you get time for your priorities is by guarding your calendar. If you know your priorities, a biproduct is knowing that anything else is unlikely to be something you want to spend time on. Sometimes you don't get a choice, but 90-99% of the time it is up to you.

When other people want a piece of your time, it may not always feel optional but it is. There are good ways to communicate "no" but we'll talk about that another time. Be gracious and kind, but also defend your time.

Allocate your time up front

You've got an idea of what you want to do, and you've now got the time to do it. The final piece of the puzzle is breaking down the work and allocating it out. Often priorities aren't as clear cut as 1 -> 2 -> 3, so you'll need to do a bit of juggling.

It's completely okay to tackle small pieces of all your priorities across the day, just make sure you're achieving something at the end of a portion of time. If it's a bug, it might just be "I've spent 2 hours working on this, and I've come out with a long list of what definetely is not causing the bug" - even that can be progress!

If you've got two projects you're working on that are your joint top priorities, just pick one to work on first. Roll a dice, flip a coin, it doesn't matter how you choose which to start on. Break down the work into a collection of small tasks, order them so you know what order you'll do them in, and then block that time out in your calendar.

Now you've got the magic combination! You have an understanding of your top priorities, free time to work on work on them, and an ordered list of small tasks to work through.

From there it's a case of getting started. I find it's much easier to get started when I know I have a start and end time for my session of deep work. I can set an alarm for a few hours time get started on the first item. My goal isn't to do the entire list, but just to spend that entire chunk of time working my way through the list I've created for myself.

Some days you'll finished feeling pumped and on a high of productivity, other days you'll drag yourself to the sofa after getting nothing ticked off the list. No amount of planning is going to change that, it's part of the ups and downs of life. So before you charge off into the sunset to subdue your priorities and decline all your managers meeting invites, just remember to have grace with yourself and with those around you.

Here's a question I get a lot.

I feel like I've been doing really well at my job since I started and think I'm ready for the next step. How do I start thinking about landing a promotion?

You'll have to jump through a variety of hoops for any promotion within any organisation. These will differ from company to company as well. Some have a well understood formal process, some may require you to apply for an open position, and sadly many still don't have a well defined method.

No matter what the process is for your workplace, you're going to need a firm foundation to pitch your promotion on. But what does that foundation look like, and how do you start to build it?

Lets start with the first question, "what should form the basis for my promotion, and how do I know when I'm ready?". This is a pretty simple one, but it's important to answer it from a few different perspectives.

• Your perspective - Once you believe you're operating at that next level, you probably want to look at a promotion of some sort. It's useful to remember that this isn't based on time in the role, but instead on whether or not you're showing that you are capable of working at that next level up. The duration of time it takes individuals to be ready for that step may vary wildly! Some of your peers may race up a few steps, others may take a bit longer.
• Your managers perspective - For a manager, a promotion is a bit of a risk. Promoting someone too early can be problematic, as you have filled a position with someone who is not yet able to carry out the requirements. That can bring a world of pain. Firstly, the job the manager needed performing is not getting done, and secondly the person in that role is now under performing and that can lead to performance improvement plans. Your manager will want to make sure you're definetely ready for a promotion, so that you can succeed and their team remains healthy with the work getting done by the right people to the right level of quality.
• Their managers perspective - You can think of this as the perspective of "the business". The business will want to promote you when there is a need for someone to fill a position above your current level. There will always be a need for you to move from a junior engineer to a mid. This is because the business needs you to become self sufficient in your work. This is quite different from trying to move from a senior engineer to an engineering manager, for example. Companies need engineering managers, but you don't need more managers than teams, that would leave someone with little work to do.

A promotion looks very different from each perspective, right? That's okay though, in most organisations you won't have a problem, you just need to make sure you satisfy each persons needs and risks.

So, you're operating happily in some of the areas of the job above yours, and the business has an opportunity for you to move into. How do you bound a foundation to sell your promotion to your manager and the business? That's where our brag document comes in!

A brag document is quite simply a list of your achievements. In particular ones which demonstrate that you're operating at the next level up. When the time comes to kick off the process of getting a promotion you don't want to be relying on your memory, you want to have a list of everything you can feed from.

What should your brag list look like? Well it's completely up to you but here's a few suggestions.

1. Start with a date and a few words describing the achievement, this will make it easy to scroll through later on.
2. List the situation, your contribution, and what the business or social impact was. You might hear this called SBI (Situation, Behaviour, Impact).
3. List some of the other people who were involved.

You might end up with something like this:

2021-03-20 - Found bug in order payment process and worked with payments team to fix.

While doing some testing of my work I noticed an issue with payment processing in production. I couldn't see anyone had reported it so I raised it with the payments team. I provided screenshots and a detailed description of the issue. Payments were able to alert the SOC and raise a production issue ticket. We tracked down the issue and I was able to confirm the final fix. This solved a case which was preventing 1% of users from completing their orders. My raising of this issue saw that resolved within 1 day of the issue being introduced and minimising our loss.

Others involved:
- James Jameson - Head of Engineering for Payments
- Abby Abbort - Principle Engineer for Orders

It's not an overwhelming amount of information, but anyone reading that can clearly see you prevented further loss to the business. That speaks to your manager and shows you're pro-active and have a sense of urgency with production bugs, and it speaks to the business and shows the bottom line impact your work had.

I recommend trying to maintain something like this and setting yourself a reminder to update it every few weeks. That way the information should be fresh in your mind when you come to write it.

The act of turning this into a promotion will depend on your organisations process. Some will have forms you need to fill out, which will likely need information from your brag doc. Other orgs may have a less formal process, and you might choose to take some examples from your doc and turn them into an application for an open position. The aim with this document is to keep an ever growing log of your achievements so they're ready to go when you're ready to take that next step.

This body of evidence should form that foundation of your promotion request. With it, you are able to clearly communicate to your manager and the business in a language which speaks to them. Without it, you'll be stuck pulling these from possibly years back in your memory.

If you've been in the industry for more than 5 minutes, you'll have probably had some recruiters tap you up on LinkedIn. But who are they, what do they do, who do they work for?

The job of a recruiter is simple, find a qualified person to fill an open position at a company.

In industries where there are more workers than jobs, it's easy to hire people. You put a sign on your door, or a page on the internet and wait for applications. In an industry where the number of jobs is greater than the number of workers, things get a little more complicated.

How does a company get their job ad seen by qualified people when there are more jobs than workers? This is where recruiters come in. The job of a recruiter is simple, find a qualified person to fill an open position at a company.

If you've not experienced it yet, you likely soon will. Within the world of tech recruiters first port of call is LinkedIn. They'll scour LinkedIn, GitHub, and other areas of the internet to find anyone who might fit the requirement of the job and will try to sell the company as a great place to work.

Because so much of recruitment is done online, getting your LinkedIn up to date is really important if you intend to engage with recruiters. They'll be using a lot of automated tools to search for candidates to get in touch with, so make sure the technologies you list are relevant to your job search. List the things you have experience with and want to work with, and consider removing those you're not interested in anymore.

It's also worth considering how you want to communicate with recruiters before you go out there. In my experience, every recruiter is desperate to get you on the phone. Why is this? Their as much sales folk as they are recruiters. They want to sell you a role and get a good read on you, this is much easier for them on the phone. They can gague your interest, pivot the conversation if needed, and figure quickly get a feel for what you would be like in an interview.

I would suggest you spend time thinking about how you want to manage communication with recruiters when you're on the job hunt. My approach to communicating with recruiters is to always start with LinkedIn. I've turned off all notifications, so it won't intrude on my day-to-day, and I can easily block someone if anything happens. My phone number and email address don't get given out until I've decided to move forward with an application.

Once they've found someone who fits the job profile and is interested in the company they then start sheparding the recruitment process. Recruiters will often want to own this process and be the single point of contact between you, the applicant, and the hiring company. As a result, they'll be responsible for sending over your CV, organising any interviews, and often some part of the compensation negotiation.

Why do they want to be in the middle of the conversations? It's all to do with how recruiters get paid. Lets take a look at the three ways a recruiter can usually get paid.

The first is the agency recruiter, these folks work for a recruitment company. The company contracts for firms looking to fill open positions. If the agency usually gets paid when a successful applicant is found, and sometimes there are caveats around the applicant passing a probationary period. In this case the individual recruiter you work with is usually getting paid a salary, however the majority of their pay will come from bonuses. Each candidate successfully placed in a job role will get them some sort of bonus. Sometimes this is commission based on final salaries, and sometimes it's a flat rate.

The second is the contract recruiters working inside the hiring company. In this case they'll tend to get paid a daily rate and usually some sort of bonus on a successful placement. Again, in this case the bonuses are often the majority of the final pay as this helps align the recruiter with companies goal. This is similar to lots of traditional sales jobs.

Finally, we have the freelance recruiter working outside the hiring company. In this case things can vary a lot, but on the whole the pay usually comes purely from a successful placement of a candidate.

The trend in the above models, is that recruiters make the majority of their income from getting a candidate through the recruitment process and into the job. This is why they want to control the entire process and act as the middleman.

A recruiter is only financially aligned with getting people into jobs, not getting people into the right jobs for them.

As a result, the interests of you, the person looking for a job, and the recruiter only line up partially. On the one hand, they want to sell you the job and, if you're successful, get you a good package so you'll accept the job. On the other hand, their insentive ends once you're in the job. The only insentive they have to ensure you're in the right job for you is their relationship with you.

This is not to say that recruiters don't care whether the job is good long term, their reputation and relationship with past applicants does mean a lot to them. However, a recruiter is only financially aligned with getting people into jobs, not getting people into the right jobs for them.

The crossover between your objective and a recruiters objective is similar to a realestate agent, they want you to feel comfortable with what you're buying. The best way to do that is with transparency and honesty about the property, but the financial alignment for them is ultimately with making the sale.

When working with recruiters it's important to understand where your interests line up with theirs, and where they depart. They want to get people into jobs, but figuring out if the job is right for you is your responsibility. Do your own research on companies you're applying to, checkout Glassdoor reviews, and ask probing questions during interviews. If the job does feel right for you then keep a good communication line with the recruiter, they're eager to get things moving quickly so they don't lose you to another job. You can also feel free to be open with recruiters and push them during negotation stages, they'll be just as eager as you are to sign on the dotted line.

Recruiters can be extremely useful if you're fortunate enough to work in an industry like tech, and if you're aware of their alignments you can make the relationship work well for both of you.

Should I get a job at a big corp, or a small startup? What's going to kick off my career on the right foot?

It's an especially common question from people who are fresh to the industry, and you'll see it debated all the way through your career. Join a hot new seed funded startup that's "going places", or join a huge company which will pay you to travel to all the big conferences?

A very common question, especially from those who are fresh to the industry, is whether you should start off in a large enterprise or a small startup. It's a hotly debated topic by everyone, even those further on in their careers. The answer probably won't surprise you - it's completely up to you. However, I do think there are some pro's and con's worth exploring with each type of organisation.

I've had the pleasure of seeing juniour engineers in both small startups and large enterprises. I can tell you right now, that both environments can be an excellent place to start your career. However, it's highly dependant on the company you join and what kind of person you are. Making the right choice is deeply personal but if you're able to find a good company at either scale, you'll probably do really well in either setting.

Life in the Startup

I started my career in a small startup, there were about 25 of us when I joined so it was very early days. The first year was amazing, I learned so much and felt so inspired every day. I felt like I was learning every day, and I had leadership opportunities opened to me early on.

This experience was wonderful, until year two came around. Year two the business was attempting some more rapid growth. I learned a really important lesson that year, when you grow something quickly, you scale up everything all at once. That includes both the good and the bad. The faster you scale the less time you have to fix the bad things.

Startups can be a wonderful place to learn if you want to be thrown in the deep-end. You'll be expected to start delivering value fairly quickly and the value you do deliver will have a very high impact. However, the contrary is also true.

Life in the Big Corp

In November 2018 I joined Just Eat Takeaway.com and started my journey in to the Enterprise life. It's been eye opening! There is a lot less pressure on the individual, and part of that is because the company is so large and thus the impact of an individual is often much smaller. That's not to say you can't have a big impact, but it is usually harder.

The biggest difference for you will be the sheer amount of resources. Large companies usually don't have a shortage of money. They also gain a lot from a 1% increase in workforce productivity, so they're willing to invest in that. In a startup of 10 people a 1% increase may not amount to much, in an organisation of 500+ people a 1% increase is the same as hiring 5 more people. Putting money into training can save an enterprise a lot of money compared to hiring, so they will happily spend that money.

An enterprise is fantastic if you want freedom, less pressure, and ample resources to pour into your learning. They will often have formal training programmes for university and bootcamp graduates. For those who are a little more senior they usually won't bat an eye lid at paying you to go to an expensive conference. Likewise, the pressure to deliver early on will also be lower.

If you're in your first couple of years in tech and you feel like you're stagnating in your growth, you should definetely consider moving on.

Learning in a startup vs an enterprise

We've explored a little bit what the life of a startup and an enterprise is, but I want to focus on comparing the learning environments for a moment.

A startup can be stressful, you'll need to put in the effort to learn yourself, and you may find it hard to do this during your work hours. To contrast that, an enterprise can often be slow moving, your opportunities to have big impact and break the norms can be a lot lower.

On the other hand, an enterprise is usually willing to throw time and money at you to help you learn. Many companies embrace personal development and will give you extra time away from work to go to conferences or take courses. Just Eat give me a generous budget, 5 days a year which I can book off, and will deal with international conferences outside of those constraints.

It's a personal choice which will be best for you. In my experience a startup was really great for me, but by the end of my second year I was burned out and completely drained. I had learned a lot but had to take a sizable break before starting anything new just to let my mind recover. Right now I'm reaping all the benefits of a big enterprise and enjoying easy training in a lower stress environment, but my work doesn't shift the companies income nearly as much as it did for a startup.

Making the choice

If you're unsure which is best for you, I would always suggest defaulting to an enterprise. This has nothing to do with the "sink or swim" we spoke about earlier, but it has everything to do with resources. If you're early on in your career, having a couple years of learning in an environment which is willing to open it's wallet is a wonderful experience. You'll find a low barrier to learning new things, and you won't be lumbered with thoughts of "if I don't deliver X, we won't make that sale".

But don't let that discourage you, if there's a product you have a passion for and you trust the people leading it, a startup can be a wonderful experience packed with challenge and opportunity. Just make sure you're critiquing it against where you are in your career, and whether it's going to help you move to the place you're trying to get to.

I'll close by saying this, no matter what you choose, focus on your learning and growth. If you're in your first couple of years in tech and you feel like you're stagnating in your growth, you should definetely consider moving on. Your primary goal in those first few years should be to learn and experience as much as you can, if you're employeer is not able to facilitate that then it's okay to move.

Which ever you choose to go with, I'm confident it'll be great! Enjoy finding a bunch of different opportunities and see what comes through.

This week I was having a chat with Anna Beltrami, she's our amazing iOS developer and is quite new to our team. We were trying to figure out some estimates for a couple pieces of work, towards the end she asked a question which got me thinking.

I think I need to be a bit more realistic with my expectations, and become better at giving estimates. I am usually too optimistic and don't take surprises into account. Do you have any tips on how to become better at giving estimates?

There are two truths in the world of software.

1. Every day you're going to get asked when something will be done.
2. No one in our industry has any idea when they're going to have anything done.

Whether you're a junior engineer on day one or a senior engineering manager with a decade of experience, you're going to be asked for estimates nearly daily. So how can you give good estimates, especially when you're new to the job?

What does a good time estimate look like?

A good estimate sets a shared expectation between you and the person asking. It should act as a starting point for conversation, and should always come with context to ensure the asker walks away feeling well informed, even when your estimate is vague. Here are the key things you want to convey with a good estimate.

1. A time range, you'll rarely be able to estimate an exact date or time for something so give a time range. 1-3 working days, 6-8 weeks, 3-4 hours - whatever your estimate is, the moment you give someone a range they know it's not a deadline you're promising but an estimate.
2. An idea of the risks that might cause a delay. When someone asks for an estimate, they don't just want a date and time, they want to learn about the progress of the task. By listing out some risks or possible reasons for delays, you open up that conversation and allow them to ask more questions.
3. A confidence level in the estimate you're giving. If you're estimating 6-8 weeks for a whole project delivery, how confident are you that it'll be within that range? Is it using all new technologies and it's a "finger in the air" estimate, or maybe it's something you've done 1000 times but you're just waiting on another team to finish a dependant piece of work.

The person asking for the estimate wants to walk away more informed, they usually don't mind if you're unsure of your estimate - they just want to learn a bit more to help enable them to progress on something themselves. Here's how one of my recent estimates sounded:

It's a pretty big piece of work, my gut says about 6-8 weeks but we've not done much investigation yet. If it's similar to X that we did last month then it'll be closer to 6 weeks, however if we want to do user testing first then it could be longer than 8 weeks still. Assuming the spec we've got doesn't change too much, I feel fairly confident we'll deliver it within 6-8 weeks.

With this estimate I've given a clear time estimate the person, in this case a Product Manager, can lean on. I've also included a bit of information about the risks, in this case we haven't done user testing, and a way the risk might be avoided. I've then given a rough idea of how confident I am in the estimate given the current spec that we both have.

How can I improve my estimates?

The central part of a good estimate is considering what might cause a delay and how likely it is that those issues will happen. This is also the core of why many estimates are wrong, you can't know every potential problem no matter how experienced you get!

Try to list out between 3 and 5 possible things that could cause the task to take longer and try to figure out which of those is most likely.

If you feel like you're struggling to make accurate estimates, there are usually two possible reasons.

1. You're not considering enough risks around a piece of work. If you think this might be the case, I would suggest taking your time over estimates, try to list out between 3 and 5 possible things that could cause the task to take longer and try to figure out which of those is most likely. For those, you'll want to add an appropriate amount of extra time onto your estimate.
2. You're working with a lot of unknowns that you are struggling to identify. This will definetely be a problem when you're in a new company, or a new job role. If you are new and this feels like it might be part of the issue, it's okay to add extra time into your estimates to account for it. You can even highlight it as a risk! It's entirely valid to say "I've never done this before so it might take me a few days more than someone else".

When you're in a new job or tackling something new, it's okay to take longer over estimates. It's quite rare that you'll be in a disaster situation and will be asked to provide an estimate for something, it's okay to ask to get back to someone, it's also okay to speak to others to get their opinions on an estimate.

Every estimate you give is an opportunity to exchange information, and build rapport with the person asking. Take time over your estimates, don't hesitate to make people aware of estimates which you're unsure about, and failing all else it's okay to say "I really can't begin to estimate that, I would need answers to X, Y, and Z first".

It's week two so that means we're on a technical topic today. I wanted to kick off with a topic that will begin for you in your pre-professional days and won't end until well after you retirement. The tool chain you use and make your own is one that will be of constant debate amongst you and your future colleagues. It'll be one of the most divisive and personal topics, and it'll also be one of the most fun.

In software engineering we're fortunate to, usually, be able to choose our own tools. Many are free, and others are often inexpensive. With this choice comes freedom and responsibility. Today we're going to talk about the common types of tools you'll need to use, how to choose which ones to invest time into, and a couple pitfalls I see newer engineers struggle with.

Aim to be agnostic, but ensure you learn one well

Far too many people get married to their tools, this is not noticeable when you have the luxury of working on your own machine. However, when you try to help out a new colleague with some tasks on their machine, you're going to wish you were more comfortable working across different operating systems and text editors.

Your end goal should be expertise in your chosen core tool chain, with a broad working skill set across other standard options. In other words, you want to be a "T Shaped" individual. The top cross of the T represents breadth of understanding across a subject area, the vertical line down represents a depth of skill in a particular area. This should be the long term goal of your skills with various tool chains. To give you an idea, here is my T shaped tool chain.

Some of my chosen daily drivers:

• Emacs / VS Code.
• Zsh with my personal configuration files.
• Git  on the command line.
• FireFox as my web browser.
• Curl the industry standard cli http client.

Other tools I have working knowledge of and can comfortably use:

• Notepad on windows, vi and nano on linux.
• Any Jetbrains IDE and Visual Studio, a popular .NET IDE.
• Bash - the most common shell on linux systems.
• PowerShell and cmd - common shells for windows.
• I can use the dev tools reasonably well in Chrome, Safari, and Edge.
• Postman, a cross platform http client.

With these tools I have some which I'm fast at using and can make use of advanced functionality, but I'm also not paralysed the moment I have to SSH or RDP onto a more minimal system. I can also get things done quickly on a colleagues machine if needed.

Avoid the OS wars

Younger me was quite dogmatic about which operating system was superior. As time has moved on, I've dropped this and I spend my time using Linux, Windows, and MacOS every week. The key thing that swayed me is the fact that there are many operating systems and as an engineer you will be forced to work on different ones throughout your career.

These days I'm not as agile with Windows as I used to be, my powershell-foo is not what it used to be. But I work across linux, mac, and windows most weeks due to the demands of the business I work in. I love discussing the pros and cons of operating systems, and there are aspects of some which drive me insane, but it is really important to realise quickly that you'll be better at your job if you can confidently work across them all. That's not to say you need to learn each inside and out, but in the first few years of your career you should try to spend some time learning the basics of mac, windows, and a linux system or two.

Common tools you'll need

Okay, so what is the base minimum toolchain you should be thinking about in your first few years? I think it's important to keep it really simple, and much of it will depend on what you're building. Here is a list of what I would suggest builds the foundation of your toolchain.

• Editor / IDE - You'll use for 85% of your work so it's important to learn one well over time. Try to understand the shortcuts and move away from the mouse when doing most of your tasks.
• Email client - This one might surprise you. Email is definetely a bore, but let me tell you. The longer you're at an organisation, and the more senior you become in your career, the more email you'll be dealing with. Treat an email clinet like your IDE, choose one, and learn it's advanced functionality like inbox rules. If possible, find one you can extend with scripts. Don't go overboard on this, Thunderbird is a great option. Many times you'll be stuck with gmail but even that can still be quite powerful.
• Shell - Use something simple and common but learn it well as you'll likely find many problems become simpler when they're in a shell. I wouldn't muck around too much with shells like zsh, or fish to start with unless all the senior folks around you are doing so. Stick to the defaults, they're just as powerful as anything else. Powershell, and Bash are great places to start.
• Operating system - This is as much a tool as anything else, make sure you're comfortable with a spread of options but commit to one to be an expert in. If Windows is your thing then that's great, as long as you're ready to hop on a linux box every so often. If you're you prefer mac, just make sure you have Remote Desktop ready to go to debug issues on a Windows server.

How to choose your brand of tools

My number one piece of advice for you when choosing tools is simple, use what the senior engineers around you are already using.

Use what the senior engineers around you are using.

Put aside everything else in your first job, and commit to using what the senior engineers are using. You might have a couple weeks of pain trying to learn the interfaces, but the moment you need help you'll have it from people who've been spending the best part of a decade using that particular piece of software.

The approach of using what everyone else is using won't be one you use forever. You'll find that as you continue over the next couple of years in your career, you'll want to start choosing tools that fit you a bit better. That's where my next few pieces of advice come in, but I want to stress the first point. If you're new to a technology or type of tool, just use what your team and seniors are using, it's a great place to start!

So you're past that point and now you're starting to make your own choices. My next category for choice is "flexibility", you want to choose a tool which will work in a variety of scenarios and tackle several tasks. By doing this you reduce the amount of tools you need to learn and you leave more room in your brain for the hard stuff. Be careful not to confuse multi-use and flexibility with "highly configurable". Configurable tools are often ones which give you a lot of flexibility, but they can also be traps ready to snare you and drag you down into the Wonderland of configuration.

Question your past choices

The tools you choose today may not be the best tools for you tomorrow. I would suggest spending a bit of time once a year critiquing and re-evaluating 1-2 of your tools. Is vscode the right editor for what you're doing now? Maybe you're better off with a more complete IDE. After doing this a few times for a given tool you'll hopefully find yourself settling on longer term happiness with that choice. This is when yo uknow you've hit the sweet spot!

You've just started your first job, you're a week in and you've spent every day so far thinking something like this:

Oh no, I know absolutely nothing! How am I possibly going to do this task? Someone's going to find out soon.

Be it imposter syndrome, or the realisation that your mistakes can lose the company money, this can be a sucky thing to experience. But let me tell you, we all go through it, and it will pass. This week I wanted to focus in on that feeling and discuss a way to react to it.

When you start your first job in the industry there are going to be two things going on. First you're going to be using your skills in a professional context for the first time, and second you'll be learning about the company you've just joined. It's easy to conflate those two things into a single ball of panic and worry. However, I think it's important to try and draw distinctions between the two. Let me unpack what I mean in a bit more detail.

It's fairly common, especially for those of you from a university background, to land in your first engineering role and have a sudden realisation that you don't know nearly as much as the others around you. This is completely normal! You've had a sudden change of environment from a place of learning with peers to a place of learning with more senior folks and mentors. This shift can take a bit of time to settle in to. The style of learning is different, and the expectation feels different. It can often be easy to lose sight of the true expectation on you. When an organisation hires a junior engineer, the majority of the time, they expect you to start by knowing very little and to learn and grow over time. Let me repeat that: the only expectation for your first few months is to learn. Soak up as much as you can and don't worry about getting it right, this is your time space and opportunity to learn and make mistakes.

The only expectation for your first few months is to learn.

Usually I find most people are okay with the idea of spending a few months just learning. The part many people often aren't expecting is just how complicated the organisation they are working for can be. Every organisation is different and sometimes the hardest part of a new job is understanding how things tick. Departments, reporting lines, roles and responsibilities, the vision, the gate keepers, and the stake holders - learning all of this takes time. It's not something anyone can or will expect you to take in on day one, no matter how good the on-boarding seminars are. It will take you time to experience these different aspects or your organisation, and in fact, after a certain size the learning never seems to stop! I've been at Just Eat for over 2 years and not a week goes by where I don't learn something new about Just Eat.

It's very easy to feel like the forest of "new things" in front of you is never ending and that you're not good enough to find your feet. The truth is that usually as a junior engineer you're experiencing a large shift in two areas, where as many more experienced engineers just have the new organisation to deal with. It can be overwhelming at first but this period of learning is fully expected of you as a junior engineer and you will ramp up much quicker than you expect.

The commonality between all of these new things is that time is a great teacher. Over time you'll tackle each question one at a time and you'll start building an intuition of how to tackle the next few. In my experience it takes a junior engineer around 3 months to be contributing at a net positive. For the time prior to that, the full expectation is that you're primarily consuming organisational resources to learn. Even after 3 months you'll continue to learn and require time from your more senior team members, but you will most likely be contributing in a way that puts you in the positive. That said, I wouldn't expect a junior engineer to be up to their full pace until at least 6 months into a role, and usually I'd expect it to take even longer. This seems to be common across most companies I've worked at despite their size.

The one thing I find myself repeating to junior engineers over and over again is this.

Give it time, and give yourself grace.

Don't panic, ask lots of questions, know that everyone around you expects and wants you to spend the majority of your time learning. As you move up through the ladder of experience you'll come to have more expected of you so treasure the time you have to learn and make the most of it. Over time you'll find your feet and will start to pick up speed, and before you know it people will be coming to you with their questions.

Keeping the beast running, and it's customers fed is pretty important since we make most of our money from orders. If you can't place an order, we can't make money, so up-time and reliability are pretty crucial to the business. Over the years we've added small rituals and strategies that we found really helpful in keeping things running.

Lets start with how we deploy things into production in the first place.

Deployments, canaries, and release warranty

Our process to deploy changes to production is usually pretty dull, which is just the way we like it. When you merge a change into master it ticks through a very straight forward pipeline. Our CI builds the latest master code and then trigger our deployment pipeline which deploys the code onto a couple of QA environments representing different types of settings. When it's on a QA environment, any automated tests will run and assuming they pass it'll then do the same thing with a staging environment. The fun comes when it gets to production.

Once we've gone through QA and Staging, we then have a button to press to start the production deployment. This allows us to spend any extra time verifying or checking changes if we need to. When you hit the button to approve the production deployment it then goes into a canary state, it'll deploy into production and will then point 20% of the production traffic to the canary instances. The amount is actually configurable per-component but most teams use 20% as a starting point.

We then leave it running in canary for a while, how long will depend on how critical the component is. Some critical components will sit in canary over night or over the weekend. This lets us collect some data and monitor metrics to make sure things are working as we expect and that we definetely haven't broken anything. Finally, when we've hopped through any other canary steps , again - configured on a component basis, we promote the canary to full production. That redirects 100% of the traffic to our new instances and tears down the old deployments.

We also practice a "release warranty", this is where we actively monitor the deployment for a short time after it's been released to catch anything we may have missed before. The warranty period is usually about 20 minutes, but again it's on a per-component basis depending on how important that feature is to the platform.

All in all, seeing a release out the door can be done in just over an hour if your builds and tests are fast. Some legacy components take longer, but that's ok, we'd rather they were don't carefully with lots of time to spot issues.

That process is all well and good, but sometimes things do go wrong. When they do go wrong we've got a pretty good process for getting through incidents.

Incidents

PagerDuty's going mental, your half asleep, and your spouse is pissed because "that bloody thing" woke them up at 2am as well. What happens next? Once you've taken the abuse and escaped the bedroom to let your partner go back to bed, the incident process kicks off. It's pretty well drilled into us before we go on-call for the first time, and it's not complicated either.

If the alerts are from automated checks then the on-call team member is likely the first responder and it's up to them to triage and figure out if it's "just a blip" or something that needs real attention. Usually we're trying to figure out if something is actually broken, or if it's just an overly sensitive check. If something is broken and it's going to have an impact they'll raise the alarm with the SOC (Service Operations Centre) team.

The alternative to this is that it's something reported by the customer care teams, customers, or the SOC have noticed it themselves. In this situation they confirm it's an issue and immedietely page the relevant teams and raise a Production Incident (PI) ticket in Jira.

SOC will raise the PI if there is a legitimate issue, that will automatically create a video call link and a room in slack. Then we get to work, the next goals after triage are:

1. Mitigate the issue, find a way to resolve the issue so it's not impacting customers or restaurants directly.
2. Diagnose the issue, often we do this as part of mitigating the problem but sometimes we don't get that luxuary. When we can mitigate early we will and we'll then diagnose after once the fire is quenched.
3. Learn and improve, once we understand what the issue was we then move to make our long term fixes and share the knowledge where relevant.

Getting a PI assigned to you also earns you a spot at the daily leadership meeting. These happen every weekday morning and review all the incidents from the past 24 hours (and the weekend, if it's Monday). Our engineering leadership get a chance to ask questions about the incident, these are never to assign blame or shout at people, it's purely to understand the trends in issues going on across the organisation. It's also a place where the leadership get to understand any ongoing risks and give the relevant people a nudge when there are long standing issues. I'd enjoy these meetings a lot more if they weren't the first thing in my calendar every time I have to attend one. Aside from that they're great learning opportunities and they work really well to keep the leadership plugged into the nitty gritty aspects of our tech.

Operation excellence

The OpEx is a simple monthly all-hands meeting for all engineers. The host walks us through the monthly operational performance against our reliability goals, some teams will present notable incidents from the past month. These are usually a 1-2 minute explanation of what happened, why, and what we've learned from it. These slots are a fantastic way for the organisation as a whole to learn about notable foot-guns. We wrap up with a couple of slots of major operational announcements, these cover a wide range of things from up coming audits, to notes on upcoming change freezes for major holidays.

I think this meeting was originally setup by our (now ex-) CIO, Dave Williams, who left the organisation a few months ago. They're now hosted by a Director of Engineering who pulls together the content and gets speakers from incidents over the last month.

The best thing about the monthly OpEx is that it's a monthly meeting / call, and you can sit there and soak everything in without any pressure to contribute if you're not on the lineup that week. The entire OpEx enforces our no-blame approach to incidents and we've learned an awful lot from them.

We have a number of other processes and rituals, but those are the corner stones of reliability at Just Eat. At the end of it all, we want to work on a stable and reliable platform that doesn't wake us up every night. Over the last 3-4 years we've made great stides forward in our operations and reliability, to the point where we're now removing many of the processes we put in place to help get us to this stage. They've served their purpose now, and we're able to move faster with higher reliability without some of them. I don't see these ones going away any time soon though, and that's probably for the best.