TL;DR:
- The good: I’ve grown *a lot as a programmer.
- The bad: my life is a lot more complicated these days.
- The same: I still like playing games more than making games.
I’ve got roughly 10 years of professional experience and more like 20 years if you include all my personal programming time. Sure, a lot of it was spent programming business software, but those skills still translate to games.
When I was young and first working on my game, I had to look up how to do every. Single. Thing. Small development tasks took way too long because I was spending more time learning than doing. I wasn’t sure how to structure my code (nor did I think it through as a younger programmer), so I had to break and refactor things all the time. Now I crank out code in an hour that would’ve taken me a week of research and experimentation. Why? Because I’ve done it before!
I’ve also learned not to fall for the classic trap of thinking I have to make everything myself. Earlier on, I wouldn’t use open source libraries or game engines because I thought I had to do it all. This time, I’m making my game in Unity. I’m not having to figure out how to make hitboxes or handle physics because Unity handles that for me. I’m not wasting time reinventing the wheel, and Unity’s “wheel” is likely better than what I would’ve made anyway!
Taken together, this means that I’m really productive when I work on my game. However…
…when am I supposed to work on my game? I have a full time job that – like many of us – keeps me occupied beyond the usual business hours. My wife and I want to spend time together, and watching me write code isn’t exactly an exciting group activity. My kids need help with homework. My kids have friends they want to hang out with and can’t drive themselves, so I have to do that sometimes. Doctor’s appointments, parent-teacher conferences, dishes, laundry, taxes, and all that other adulting stuff.
In my 20’s, I had so much free time. I could’ve done so much more, but all I wanted to do was have fun. I wasn’t in a hurry to finish my bachelor’s degree (much less get a master’s), I wasn’t as concerned about my physical health, and I thought I’d have plenty of time to finish making a game. I put a lot of important things off, and now I don’t have all that free time. I’ve got all these important things to do, but I still want to have fun.
That’s exactly why, when I do work on my game, I fall back into a bad old habit.
When you change software, it’s important to test that it works. You write code to add a button, run your code, go to the changed page, try clicking your button, make sure input is validated, etc etc, and then you go back to coding. But what happens when the change you made is creating a new laser weapon?
Man, this looks cool. I wonder if I added more particle effects? Five minutes go by. All these particles are awesome. I bet they’d look killer in slow motion! You set the game speed to 25%. Ten more minutes go by. Okay, now what if the laser is green? No, purple! Let me try all the colors! Before you know it, you’ve wasted an hour playing with your new feature.
This is the one thing that hasn’t changed. I have probably spent more time playing my games than actually creating them. I also like to do, ahem, “market research”. I’ll go play a bunch of other games in the same genre for “inspiration”. I’m not just playing games, I’m analyzing how they work and gathering ideas! Sure you are, Noah. Keep telling yourself that.
All that aside, I still want to work on my game. I don’t have a ton of free time, and the urge to play games is really hard to fight, but I’m going to make it happen. I’ll try to – like with this blog – commit a little bit of time throughout the week to tweak things. Importantly, I’ll save the source code so that I can keep working on it long-term. Maybe one of these days I’ll have a finished game.
But not anytime soon – I’ve got a lot of “market research” to do first! 😬
]]>TL;DR:
- Everybody is great. Too great. I must be an imposter! 😭
- Onboarding was like drinking from a firehouse.
- Feature flags are so, so good!
- So much non-code work is required in a place this big.
It feels like I’m surrounded by rockstars, and it’s hard not to feel like an imposter. When I meet a new coworker, I like to pull them up on LinkedIn. With my Google coworkers, it feels like everybody graduated from Harvard and MIT. They’ve all worked at multiple huge companies. They’ve written books and hold patents. I’ve seen more people with master’s degrees in the past few months than I saw in years at other companies. The amount of talent inside of Google is outrageous.
You’d think that all these smart people would be narcissistic, arrogant jerks, but the opposite is true! To get into Google, I had to pass 5 different interviews. Every single interviewer was super nice to me. The recruiters I talked to were pleasant. Every single member of my team is incredibly helpful. Anyone I ask for help is quick to jump in and help. I ask if somebody can point me in the right direction and they give me a link to a specific doc or piece of code that answers 100% of my question.
I have yet to meet someone that isn’t incredibly smart and ridiculously nice. People talk all kinds of trash about their strict interview process, but it clearly works.
Google has been around since 1998. Many software tools didn’t exist back then, so Google had to make their own. Some of those tools (Angular, Golang, Guava, etc) ended up being used outside of Google. Other things split off and became their own thing. For example: other organizations use Kubernetes but Google still uses Borg, the cluster manager that K8s was based on.
There is a convenient list in Google called “inside/outside” that lists all these things. We use Piper, not Git. Buganizer, not Jira. Critique, not GitHub for code reviews. We call them CLs (change lists) instead of PRs (pull requests). I could go on – it’s kind of a big list.
Trying to learn all these internal tools and terminology was a lot. The first weeks at Google involve going through an onboarding program, and it is often described as drinking out of a firehose. Once I got inside, I understood why the interviews don’t test for a particular language. It wouldn’t matter if you were an expert in Java, you would still have to learn all the internal libraries that only exist in Google. It doesn’t matter how much you’ve used other tools, because Google’s tools are just a little bit different and you have to learn how to use them. Prior knowledge helps you ramp up faster, but there’s no way you’ll come in and already know how everything works.
At other jobs, we all worked on pieces of a release and it all went out the door together. Not at Google. At Google, every change is scoped to be as small as possible and is gated by a feature flag. Instead of doing an entire code release, you flip a switch to turn a flag on. If your change unexpectedly breaks things, you turn it off and fix things. As a result, nothing breaks for long.
Flags aren’t simply on/off switches, either. You can turn a flag on gradually and ramp up to a 100% release slowly, checking for problems along the way. You can define all kinds of characteristics (or combinations of characteristics) to determine which users get a feature. Only want to test your code on users of certain products in a particular region? No problem. Want to run an A/B test to see which new design reduces the bounce rate? Easy!
I’m so spoiled by feature flags now. One of these days I’m going to work somewhere with a traditional release cycle, and I’m going to hate it. Flags are so powerful, and I wish every place had a robust system to do it like Google does.
I knew that my job at Google would involve writing code. What I didn’t expect is how much other stuff I’d have to do.
Anything more than a trivial change requires a design document. Each service is used by other teams, so you need to constantly update technical documentation and instructions. If a change might affect multiple services, there might need to be a discussion to coordinate and make nobody’s changes have harmful side effects.
Legal reviews, accessibility reviews, security reviews, code reviews – lots and lots and lots of reviews. Google is a huge international company that has to comply with a lot of regulations. Hackers and fruadsters are constantly looking for ways to exploit Google for money. You can’t let your code open a door for them.
You turn on your feature and watch for errors. You review logs and data to make sure you haven’t broken anything. Sometimes those feature flags power A/B experiments. You have to review the results of such experiments and discuss them with your team. Metrics have to be gathered to measure if each feature was a success. Discussions about previous experiments guide future development.
There is so much that isn’t programming. Unlike other places, where there were many unnecessary meetings, Google actively tries to cancel pointless toil. All this extra is the totally necessary stuff that remains, and it’s a lot.
Long story short: I love it here. It’s been overwhelming and stressful, but it’s been great at the same time. One day, when I’m out of Google, I’m going to miss all its weird quirks.
]]>TL;DR:
- ❤ I love automated testing.
- 😡 I hate automated testing.
- 🎓 Learn it early before you establish bad habits, and you’ll hate it less.
Consider this scenario: A serious flaw was just discovered in an important library your project uses. The only way to fix it is to upgrade to the newest version, but there will be many breaking changes.
How can you know what will actually break? Automated tests.
A third-party service you use just jacked up their prices, so your company has decided to switch vendors. If things break in Production, it would cost the company tons of money for every minute that your product is broken.
How can you be confident that you won’t cost the company millions? Automated tests!
Your code and database have become bloated over time. You’re pretty sure this code isn’t called by anything, and you don’t think we need these database tables anymore.
How can you be sure that these removals won’t crash the whole system? *Automated tests.”
Your software architecture is a bunch of microservices. As things expand, the number of possible connections between services grows exponentially. Your company is successful and keeps growing, and now it’s so big that no single person could possibly know every single thing that might be calling any one piece of code.
How can you not worry that changing literally anything might break something in some faraway code? Automated integration tests!!
“Okay, so automated tests can really save your bacon, I get it. But I’m just working on this small project, so I don’t need to write any tests right now. I’m going to keep things simple and write my code in a simple way.”
Well what happens when your “little project” proves useful and becomes its own fully fledged product in the company? Suddenly you want all those benefits, but you have to refactor literally everything in your project. You won’t know if it’ll break because (obviously) you don’t have any automated tests yet!
Getting started is hard enough. Adding tests makes that even harder. But adding tests when you’ve already got a complicated project is painful. I understand why nobody really wants to do it.
“Somebody’s boss decided automated testing is important, and now we have to raise our code coverage to 100%. Now I have to write hundreds of tests to try *every single possibility and make sure every line of code gets hit. Ughhhh!”*
And what ends up happening is people write bad tests because they’re chasing an arbitrary metric. Their test calls every path of the code, but they don’t check the part of the ouput that actually changes in that path. They don’t use parameterized tests, so they create dozens of tests that only vary by one line. Now nobody wants to maintain those when code changes.
“I uploaded my code and ran all the tests. They passed! Somebody approved my pull request. I try to complete it, the integration tests run again. They failed! Wait, they failed? But I didn’t change anything! And now I can’t complete my pull request! Now what!?”
Sure, the integration tests help you make sure all your complicated services don’t break each other. But starting a bunch of test services processing power and memory. You don’t want to slow down Production, so those resources are given to tests at a lower priority. So it’s no surprise when things take too long and time out. Now you’re wondering, “can I ignore this? Do I have to fix their broken test? Or is something actually wrong with my code?”.
Flakiness is a huge frustration and wastes so much time. The more it happens, the more legitimate test failures get ignored. Because of the random nature of the errors, it can be a nightmare to diagnose the problem.
Automated tests are like exercise. If you’re fit and in shape, it’s really easy to exercise. But if you slack off for years and let yourself get out of shape, it suddenly becomes an uphill battle. The longer you go without exercise, the more of a struggle it is.
I wish I’d learned about automated tests when I first learned to code. I wish I started every project by writing tests that fail. But I have bad habits. I have to remind myself before I get too far to stop and write some tests. I groan about it every time, but I’m always glad to have the tests when they’re done.
If you’re reading this, are a computer programmer, and aren’t already writing automated tests, you need to start. Don’t do anything else until you have written some tests for your code. Trust me, it’s worth it. The sooner you start, the better. You might not see the point yet, but I promise you: one day an automated test is going to avert a disaster and you will be thankful for them.
]]>TL;DR:
- The good: “Digital gardening” is a decent way to get started
- The bad: It’s still easy to neglect your “garden”
- The bottom line: Be honest with yourself about how much time you have
I have started plenty of projects, blogs, etc, only to have them go nowhere. I didn’t want that to happen with this site, so I committed to doing it little by little. In that regard, the digital gardening experiment was a huge success. Rather than having a 90%-done site that nobody could see, the site got out immediately and grew into what it is now.
My plan was to use this “digital gardening” approach for my personal projects, too. Rather than try to finish every single thing, I wanted to slowly work on it. It turns out that it takes more discipline than I was prepared for, as I will get into next.
What happens when you create a garden and then walk away from it for months? Things wilt, wither, and die. Unfortunately, that’s what happened with me.
At several points I looked at my site and realized I hadn’t written a post in a while. Suddenly, instead of “I’ll work on this a little here and there” it became “I need to write 3 blog posts right now!” That defeated the whole point of a relaxed gardening-like experience.
Originally, I told myself I’d write a post every week. Then I decided every two weeks was better. Two weeks turned into a month. I severely underestimated how long it’d take me to write each post.
If you’re going to start a thing and promise yourself that you’ll work on it, be honest with yourself. How much time do you really have to do this? I’ve got a full time job and a house full of kids. I’m busy all the time, so carving out 30 minutes to write something is harder than it sounds. Everybody’s situation varies, so I can’t tell you how much work your digital garden will take. All I can suggest is that you start small.
Gardens also don’t have to be perfect. This is something I’m still struggling with. I’m the type of person to write an email and then read and re-write it 100 times before I send it. Simple messages that should take me 30 seconds to write end up taking 30 minutes because I’m overthinking it. If you’re that type of person, you’ve got to relax and fire off posts without thinking so much. You can always go back and make corrections later, after all. As Voltaire said, “perfect is the enemy of good.” Don’t let your perfectionism get in the way of progress.
Digital gardening is a good idea, but it isn’t a silver bullet. Whether you finish a project before putting it out there or let it grow slowly in public, you still have to put in the work. Putting something out there half-finished may give you the motivation to keep going, or it might stress you out when you see that your half-done project looks, well, half-done.
The most important thing is to be honest with yourself. Don’t commit to doing something every day if you only really have time to do it once a week, or once per month. Any timeline is fine, but if you try to make yourself too much you’ll stress yourself out, whether gardening or not.
]]>TL;DR:
- I do all my work at Google on a Chromebook, and it has worked surprisingly well.
- Have a GitHub repo? Hit
.on your keyboard to edit in your browser.- Thanks to Chrome Remote Desktop, I’ll never need a heavy laptop again!
While it is possible to install VS Code directly onto a Chromebook, that’s not how I write code at Google. Instead, I use a web-based editor directly in Chrome. This is made possible by Google’s so-called Client in the Cloud (CitC). Basically, instead of creating a local branch of the code repo, you create a new workspace that exists in the cloud to track your changes. I make changes in a web-based editor, and those changes are immediately saved back to the cloud.
“But I don’t have Google’s cloud to host my code!” you say? Maybe not, but you do have Github!
Go to any repo you have and press . (period) on your keyboard. This will redirect you from Github.com to Github.dev and open a web version of VS Code. You can edit your code directly in the browser and merge your changes without ever having to install an editor to your machine! In fact, I’m writing this blog post in Chrome right now.
As cool as editting code in the web is, there are times when you need something more than Chrome OS can give you. That’s where Chrome Remote Desktop (CRD) comes in. I have used all kinds of different software to remote into computers over the years, and CRD has been by far the easiest to set up and use.
Simply go to https://g.co/crd/setup from the computer you want to access remotely and install the software. From another computer (or your phone / tablet!), visit https://remotedesktop.google.com/ and you’ll see any computers where you’ve set up CRD. Click one, enter the PIN you choose when installing CRD, and you’re in – it’s really that simple.
If I want to do development that won’t work in the browser (game development in Unity, for example), I remote into my powerful desktop from my lightweight Chromebook. Never again will I need a big, heavy gaming laptop to do development on the go – instead I can save money by having a tricked out desktop and a super lightweight Chromebook.
Unfortunately, Chrome Remote Desktop is not good for gaming! Things are responsive enough for programming and general computer use, but it was clearly not meant for running games. For that, you’ll want to look into Steam Link or Moonlight – they take a little more to set up, but they’ll let you play games remotely just fine. It’s important to note that the computer streaming the games should be hard-wired for best performance. If you’re like me and have a big desktop sitting next to your router, this shouldn’t be a problem.
The other option is to use something like XBox Cloud Gaming. If you have Game Pass, you may already have access to this without knowing it. Go to https://www.xbox.com/en-us/play, sign in, and play games directly in your browser. You’ll need a decent internet connection, but it works surprisingly well.
Since getting everything set up, I haven’t played video games on anything but my phone and Chromebook – and I’ll never go back. I don’t miss my heavy gaming laptop at all. I definitely don’t miss its bad battery life, loud fans, and the stream of hot air that burned my thighs if I played games for too long. I’m all-in on cloud computing and gaming!
I’ll be honest: I didn’t think we’d get to this point as fast as we did. I remember having serious reservations about Google Stadia when it was first announced. I never thought I’d be sitting here on a Chromebook, using it for serious tasks like programming or gaming. It feels like it’s happened all of a sudden, but suddenly Chromebooks are more than a novelty or a cheap computer for students, and I love it.
]]>I get these questions all the time. For a long time, I didn’t have a great answer. I got started roughly 20 years ago - not only do I not remember exactly how it went, a lot has changed since then. Since people keep asking, I took some time to write out some advice for those who are trying to get into programming.
TL;DR:
- Get started. Taking that first step and doing anything is more important than having a perfect plan.
- Find something you want to make. This will keep you motivated to keep going.
- Tackle your project in tiny little chunks and don’t get hung up on what’s going on under the hood.
Many of the people who ask me about this are trying to figure out how to get started with programming, but haven’t actually started. They looked up resources and couldn’t decide which one to use, so they stalled out. I get it - there are a TON of resources out there. It’s hard to choose - so don’t! Use the first learning resource you can find. Stick with it for a little while and if you really hate it, switch to something else. Just because you start off watching some person’s YouTube channel doesn’t mean that has to be your only learning resource. You can use them all!
Okay, so this is one area where you do need to make a decision. When you’re first starting out, you’ll want to stick with one language and not hop around constantly. Which language you work with will depend heavily on what you are trying to do. Below, I’ll talk about the importance of having a passion project. Knowing what that project is will help you decide what language to learn. For example:
Once you pick a project, look up similar projects and find out what language(s) they use. The goal here is to make sure that there are plenty of resources for you to use. Can you write a web app with C#? Yeah, but you’re going to find a lot more information for web programming in JavaScript than you will for C#. Make things easy for yourself by using the language that has the most tutorials / documentation for the thing you want to do.
Now for the real question: what project are you going to do?
I got into programming because I loved video games. Not only did I find them fun and engaging, I was fascinated with how they were made. I always wanted to make my own, so I’ve been tinkering with game design for as long as I can remember. Game programming is not easy - it’s honestly not a very good place to start learning code at all - but because it was something I was passionate about, I kept going no matter how tough it got.
You need to find your own passion project. It can be almost anything, but it should ideally have a few qualities:
Almost every programmer I know of has little side projects. They couldn’t find a tool to do a thing they wanted to do, so they made their own. Existing solutions frustrated them, so they made something that worked for them. Sometimes, these tools expand into actual products - like how Slack started as an internal tool for a game company - but often they are strange little things that are only useful to the person who made it, and that’s totally fine! The important part is that YOU want to make the thing you’re making.
Years ago, I started telling people that programming is like magic. Harry Potter and I do the same thing - we recite some words in the correct sequence and magic happens. I don’t know how it all works, and the students at Hogwarts have no idea how their magic happens - we just know what words to say! Students who I have told this to say it makes it easier to learn to code.
Why? Because many programming students fall into the same trap: we want to know how it all works. Many of us are quick to dive deep and find out what makes things tick, but it quickly turns into a “can’t see the forest for the trees” situation. When working on your project, you need to step back and look at the big picture. If you’re not sure where to start in creating your app or building your website, follow these steps:
1) Forget about code and describe - in plain English sentences - what your program needs to do. Write down what the user will do and what you expect to happen in response. Once more, with emphasis: you aren’t thinking in technical terms at this point. 2) Break your steps into many, smaller steps - still as plain English. Instead of “the user logs in” you want something like “user clicks ‘log in’ link. Login form loads. User types in username and password. System validates password. Home page is loaded with user info in the corner.” The more you break it down, the easier step 3 becomes. 3) Now we think about code! Solve each step you created above like its own tiny programming challenge. Instead of having one big, daunting task, now you have a bunch of small, manageable tasks.
This is a great workflow for a few reasons. Number one, if you ever work professionally as a programmer this is how work gets defined and divided up. Secondly, there is the psychology effect. If you only look at the peak of the mountain you’re climbing, it can feel overwhelming, like you’ll never climb that far. Instead, you want to focus on getting to your next stopping point, your next handhold - whatever gets you one tiny step closer to the top. As you complete each task, you can have the satisfying experience of scratching it off of your to-do list. This will motivate you to keep going, and you’ll end up getting a ton more accomplished.
When I learned to program, there were so few resources. Now there are so many freely available tutorials, videos, tools, and people willing to help you get into software development. There’s no need to wait around until you can take a programming class or attend a bootcamp - you can start teaching yourself right now. If you have even a faint interest in programming, I highly suggest you go out there, pick a project, and start working on it!
]]>TL;DR:
I just completed my final for a college class, and it asked me to look at Web 3.0 trends and make some predictions. After reading up on a lot of Web 3.0 stuff and looking back at the history of Web 2.0, I came to the following conclusion:
Everybody has got Web 3.0 all wrong!
Please, allow me to explain
My assignment had me look at a piece of internet history known as the Cluetrain Manifesto. That webpage (later turned into a book) was written by a handful of men who had some very opinionated ideas about the future of the internet. Feel free to read through it, since it’s all available online, but I’ll summarize some of their thoughts:
1) “The man” is keeping the little guy down. Web 2.0 is going to fix that! 2) Big business is trying to squeeze money out of the web. Web 2.0 will make sure the individual is the one making money! 3) Companies don’t talk to us like people, but the internet will force them to be more human!
According to the Cluetrain Manifesto, the future was going to be all sunshine and rainbows. We’d be able to speak out minds, make money, and be treated like people, and there would be absolutely no downside at all! There are some pretty obvious problems with the things they specifically said would happen, such as:
1) Yeah, the internet circumvents censorship. It also lets conspiracy theorists post misinformation, helps pedophiles form support groups, and enables the doxxing and harassment of people offline. 2) Sure, some individuals make money on the internet. They do that on the backs of giant companies. Influencers shill their products, free websites are powered by their ads, and our personal information is bought and sold on a massive scale without us seeing a dime. 3) While some companies try to talk to Fellow Kids™ online, individuals have adopted communication more like corporations. We pick and choose what we share online and try to present our best selves, resulting in psychological harm to ourselves and others.
Go watch any YouTube video about Web 3.0 or read any Medium article about it. You’ll very quickly notice that, according to the proponents of Web 3.0, all our troubles will soon be solved thanks to new technology. They claim that blockchain will allow us to break free of social media platforms and speak out minds, monetize our works by tokenizing them, and wrest control from the oppressive big companies.
Sound familiar?
Like the guys who wrote a manifesto over 20 years ago, these people think Web 3.0 will solve all our problems. They also don’t seem to think it will cause any problems of its own. Criminals using BitCoin? No way, people blow that out of proportion! Losing all your NFT’s because you forgot a password and there’s no central entity to recover it? I’m sure that won’t happen often! And there’s no telling what other harm may come, because it’s all too new. In fact…
I think there will be a cool use for all this new technology, but I don’t think we’ve found it yet. If you look at how the Cluetrain Manifesto describes the future, you’ll see that they’re basically describing communication as it was in 1999, but MORE! They didn’t know that dynamic web pages would allow for endlessly scrolling social media, that high quality cameras on phones would allow anybody to create content, that AI would allow everybody to look like a dog in their photos, or that WebGL would allow a rich ecosystem of indie games on sites like itch.io. The new tech hadn’t been around long enough for these great ideas to come up, and it turns out the future is hard to predict.
Similarly, I think all the Web 3.0 fancy schmancy stuff will result in something really cool. I don’t think it’s going to be “Facebook… but with cryptocurrency!” or “YouTube, but your videos are NFTs!” or anything like that. The average internet user has no use for these things in their current state, just like most people weren’t on internet forums in the 1990’s. Nowadays, everybody and their grandma is on Facebook. Somewhere, somebody is working on something using Web 3.0 tech that will become an ubiquitous part of every day life. What is that thing?
Nobody knows!
No matter what that cool thing is, it isn’t going to be a 1-to-1 replacement for what’s around right now. How can I be so sure? Web 1.0 was the age of the static web. HTML was just markup - it arranged things and applied styles and that’s it. Nothing changed, nothing was dynamic. Web 2.0 changed that.
But static webpages didn’t go away. You’re reading one right now. I don’t need this page to be dynamic. I also don’t need it to use blockchain. No amount of Web 3.0 adoption is going to change that. New technology will add to the internet ecosystem and, yes, some things will likely fall by the wayside, but others will persist. Intelligent humans exist alongside the same dumb microorganisms that have been around for billions of years - survival of the fittest doesn’t mean absolute replacement of old with new.
New technology is exciting. I can’t wait to see the internet is like in 20 years. But 20 years ago, I never could have predicted what today’s internet is like. I’m not going to bother making predictions, I’ll just wait and see what excitement comes with new technology. I’ll also keep an eye out for the new harm that the new technology will bring - hopefully we’ve learned our lessons from the past, but I honestly doubt it.
]]>TL;DR:
- Stop working so much! Not just for your mental health, but because it will make you better when you are working.
- Communicate, communicate, communicate. This is important in person, but it’s more important when remote.
- Invest in your setup. Your company might cover some equipment costs. Even if they don’t, it’s worth the money to have the stuff you’d have in a traditional office.
- Physical fitness. Working from home makes it easy to over-snack and be lazy, but it also affords opportunities to stay fit that an office does not.
In March of 2020 I started my first civilian job outside of the Air Force. March of 2020 is also right about the time the entire world shut down due to COVID-19. The day I was supposed to start was the day the company decided to have everybody work from home in order to limit spread of the virus. I went into the office just long enough to get my laptop and some instructions, then I went home.
This was my first civilian job since joining the Air Force 9 years earlier. I had never worked remotely before. I also had four kids at home who were sent home on an early spring break that would end up lasting nearly two years. These early days of remote work were a struggle, but I learned some lessons that I’d like to share.
If you were in an office, you’d show up at 9am and go home at 5pm. Maybe you stay a few minutes late to finish something you’re in the middle of. Occassionally you might come in really early or on the weekend to do a code release. Generally speaking, unless there is some sort of emergency, you stick to your core working hours. When you have to work extra, your boss might let you go early the next day to compensate.
Working from home makes it really easy to never stop working. This is because you never really leave the office if your office is at home. You need to create boundaries, both with your coworkers and with yourself.
Make it obvious when you aren’t “at work”. Set your online status to away at 5pm, set your core working hours in the calendar program, and have a recurring meeting at lunch time to block other calendar invites. If somebody schedules something on top of those times and it isn’t really important, ask them to reschedule or see if you can miss it. If you let them trump your existing meetings a few times, they’ll keep doing it forever.
When your phone buzzes at 9pm, don’t even look at it. If it’s really important, they will call you. In fact, turn work notifications off between certain hours. Just because somebody else refuses to set boundaries doesn’t mean you should be dragged into it, too.
Many people use their commute to shift gears mentally. On the drive in, you think about the day’s agenda and what you need to work on. While driving home, you’re planning out dinner and what TV shows you want to watch with your family. Give yourself a work-from-home “commute”. For example: I listen to news podcasts and walk around my house - a direct replacement to driving into work and listening to news radio. At the end of the day, I walk into the kitchen and see what we’re doing for dinner.
To help further separate work from home, add physical barriers. Some people have a dedicated office, and when they finish work they shut the office door and do not go back in until the next day. If nothing else, shut your computer down so you’d have to log back in. The idea is to raise obstacles. Driving back to the office at you get home is a pain, and you’ll only do it for emergencies. Make getting back into work a pain, and you’re less likely to do it.
This all might seem really selfish, but it will help you out. Your brain and body need time to rest. If you constantly work, you do not give yourself time to recharge. In fact, a Stanford study showed that people who work 70 hours are no more productive than somebody who works 55 hours a week1. All they’re doing is robbing 15 more hours from their personal lives.
I have 4 kids, one of which who is profoundly disabled and requires full-time care. I have no choice but to leave at quitting time and notot look back - my family needs me. This worried me at first, but I noticed that that Stanford study found: I got just as much done as the people who were still sending emails at 9pm. I started each day well-rested and clear-headed, and I cranked out all the work I needed to in the 8 hours I dedicated to work. My family and the business were happier for it.
Not only is communication more important when remote, it’s more difficult. This is especially true for management. It’s really easy to walk over to an employee’s desk and see what they’re up to. When you’re at home, your manager has no idea what you’re doing from moment to moment.
You aren’t going to run into people on the way to the bathroom or while eating lunch. You need to make it a point to communicate with your team. Get to know them both personally (to build trust and comraderie) and professionally (so you know who to ask for help). Nobody is going to walk by and see you struggle - if you get stuck you have to reach out and ask for help.
Since your manager can’t see how hard you are working, you absolutely need to keep track of your accomplishments. If your company has a formal review process, these notes will make that really easy to accomplish. Otherwise, it’ll be your evidence to argue for the promotion or raise you want. Best case scenario, you’ve got metrics that show impact. Instead of “closed bug 1234” you want things like “restored access to the system for 1000 users”. That impact shows how your contributions help the bottom line, aka: how much money are you worth.
Offices have all kinds of nice stuff. Fancy chairs with lumbar support, multiple monitors, great lighting, ergonomic everything - the whole nine yards! When I started working from home, I was hunched over a laptop in a hard wooden chair at the dining room table.
Over time, I have added more and more to my home office set up. I don’t have a huge desk, but I like having multiple monitors, so I got a vertical stand to stack my monitors #ad and maximize space. My kids generate a lot of background noise, so I broke down and got nicer headphones with noise cancelling #ad so my coworkers could hear me instead of my children. If your company has a deal with an office furniture company and you can get a discount on a nice chair, do it! Your back will thank you later.
My latest great purchase is a desk that sits on top of my treadmill #ad. It was way cheaper than a standing desk, and it lets me stay more active, which brings me to my next point:
When I went into work, I brought my lunch. In the morning, I could make good decisions about what I would eat. I walked around the office to talk to different people, sometimes totalling more than a mile according to my fitness watch. It was easy to control my diet and stay active.
At home, the pantry is 10 feet away from me. There’s a fridge full of enough food to feed 6 people. The only person to talk to is my wife, and I can see her just by leaning. It’s so easy to over-eat and under-move, and my weight quickly started to rise once I started working from home. Here’s how I got back into shape:
Some people get up extra early and hit the gym before going to the office. That gives them time to drive the extra distance and shower off afterwards. When you’re at home, you can just exercise there. Get you some weights, or a treadmill, or a VR headset with some fitness games. Look up yoga or calisthenics videos on YouTube (there are tons out there). Burn some calories, get sweaty, and then go straight to work. You’re at home where nobody can smell you or see the sweat pouring out of you - take advantage of that!
That treadmill desk I talked about? I set my laptop on that and set the treadmill to 1 MPH - pretty much the slowest it can go. It’s basically just enough that I have to move at all, rather than sit in a chair all day. I get in the zone and start coding, and before I know it I’ve clocked multiple hours on the treadmill and burned hundreds of calories.
You can do something similar without a treadmill. Set a timer and every half hour get up and walk around or do some pushups. It won’t seem like much, but even a tiny bit of exercise is better than zero exercise. Start small and build up from there!
If you find yourself overeating, set some rules. Do what you would do in the office - pack a lunch! Plan your meal ahead of time and stick to it. If you let yoursef raid the fridge when you’re hungry and piece together a meal, you’re probably going to make some bad decisions.
My biggest advice: get a calorie counting app and let it do the hard work of totaling things up. Be honest and track everything, and see how that compares to what your in-office food intake would be. A little data goes a long way towards driving better decisions.
Working from home was a huge change for me, but it has overall been a great experience. It’s certainly not for everybody, and it does take some extra work that in-person work doesn’t need, but the unique benefits are perfect for many people. Hopefully these tips help you adjust to working from home and make you more effective in your remote work.
TL;DR:
You just graduated college with a shiny new Computer Science degree. You’re excited to go out into the workforce and get paid to write software. You aced all your classes and made some awesome little apps along the way. Maybe you even paired up with a few other students to collaborate on a bigger project. You nail the interview, get the job, and immediately realize:
There’s a lot college doesn’t teach you!
Don’t get me wrong: a CS degree is a great foundation on which to build a career. The problem is that you can’t simulate the conditions of a work environment - not in a college, not in a bootcamp, not as a self-taught developer. This post is about all the things you need to be a software engineer but won’t learn in school.
Working on a software development team is not like working alone. It’s not even like working with a group of CS students on a project. For starters:
While learning, you’re surrounded by other people learning how to program. You have jargon and inside jokes that everybody gets… until you start interacting with people who are not programmers.
Depending on the size of your company, you may have all sorts of roles on your team. Product manager, program manager, UX designers, operations, product owners, quality assurance, and maybe even end users may all be part of your team. You have to get comfortable with talking to all these people in order to get things done. Some things to keep in mind:
Maybe you’ve never used Git. Maybe you have a Github profile with all your projects on there. Either way, using it on a team is a whole other beast.
It is incredibly rare for code and work to be so well-organized that each programmer is working on a different subset of the overall codebase. You are almost guaranteed to, at some point, modify a file that another coder is also working on. If you don’t commit first, it’ll be up to you to resolve those conflicts. Sometimes, you’re referencing a file they changed and, when you pull down recent changes, it breaks all your stuff.
The breaking changes may not even come from somebody on your team. You might have to reach out and talk with whoever made the change to understand it, which brings us to…
The smaller the team, the shorter the distance is between any two people. As organizations grow, it becomes impossible for everybody to have a direct line of communication to everybody else.
In the above example, where somebody else’s code broke yours, you might be able to look at the commit history and message that person directly. Or you might have to talk to your project manager, who will talk to the other team’s product manager, who will determine if that coder has time to spare, and maybe then you’ll get to meet with them. Unless you’re coming into software from a some place with a lot of red tape (like the Air Force) the bureaucracy can take you by surprise.
Make sure you understand the chain of communication before you need to use it. If you wait to the last minute to try and talk to somebody and it turns out it’ll be a week-long process, it’s too late. If you know that in advance, you can start the ball rolling at the first sign of trouble.
When you’re programming on your own or with a small team, it is easy to take 100% ownership of your code. It’s your baby, and you nurture and care for it. You get excited to see it grow up and go out in the world. I’ve got bad news for you:
“Your baby” is going to get destroyed
As the new kid on the block, you probably aren’t going to be committing code willy-nilly whenever you want. There will almost certainly be a code review process which may include automated and human checks that stop you from making changes.
You need to be humble. People with much more experience than you are going to look at your code and criticize it. Don’t get offended - pay attention and learn. Some of it may be best practices that you don’t know yet. Some of it may be picky little preferences at that company. You may not like those preferences, but if that’s the standard they are following you should go along with it.
Also: don’t be afraid to push back. If you had a good reason to do something a weird way, feel free to explain that and see if their criticism stands. You can head this off by including good comments around any strange code you make.
When you have many people in one codebase, it’s easy for things to become messy. Not only that, but software engineers switch jobs pretty regularly. The result is that you put code into the codebase and somebody else may almost immediately be changing it because of some requirement they have.
If your code broke their stuff, they may not even talk to you about it. They might take it upon themselves to fix it - or worse “fix” it and break your stuff instead. You may come back to code you wrote and find that it is drastically different a few months later.
I’ll say it again: don’t take it personally. Every programmer has their quirks and their way of doing things. Their changes may have been needed, or it may have been them “making the code cleaner” by asserting their personal preferences. As long as it all works, brush it off and move along.
In college, you get an assignment and do it. Imagine if halfway through completing a major assignment your professor told the class they “decided to go a different way” and assigned a completely different assignment.
Pretty frustrating, right?
This happens in the business world. All. The. Time. Trends change, business needs shift, and decisions are made way above your head that will affect what code you write. Sometimes this means getting 90% done with something and then being told “nah, we don’t need that after all!”
My advice: try to keep your changes small and quick. That keeps you from having some MASSIVE change that gets abandoned.
Many programmers value elegant code. We all want our code to look nice. Programmers love to proudly post their one-line functions that do a million things. It’s so compact, it’s beautiful! I hate to break it to you, but that’s probably not going to happen on the job.
I already said that everybody has their own quirks and preferences. The business may have styles they enforce. Individual teams may have their own standards. All of those different quirks, standards, and preferences may exist in a single codebase simultaneously. People come and go all the time, so a single file may contain the quirks and weird habits of dozens of different programmers.
Do your best to conform to the habits of those around you so the code base is consistent. Not everybody will do this, because “I don’t like how they do it,” but that results in messy, inconsistent code. Suck it up, and go with the flow to try and maintain some consistency. If you really want to change the standards, talk about it as a team - don’t just up and decide to do things your way.
When you’re working for a business, you’re trying to produce value for its customers. At the end of the day, money drives every decision that a business makes. The faster they can make that money, the better. The happier the customers are, the more money they will spend. I’ve got bad news, bud:
Elegant code doesn’t make more money.
The customer can’t see your code. The CEO isn’t looking at it (except maybe in a really tiny startup). They want to know one thing: can the feature ship? Yeah? SHIP IT!! 🚀🚀 You didn’t have time to clean up the code? Will that break things? No? Alright, we’ll come back and do it later when there’s time. Spoiler alert: there’s never time!
Colleges and bootcamps are about learning as an individual. Business is about delivering value to customers as a team. Aside from the fact that code is involved, these two environments are completely different. Your first software job will be a rush of new things that you will feel unprepared for. I hope this post helps you get past those initial bumps and onto a long, successful career as a software developer. Thanks for reading, and good luck out there!
]]>The TL;DR version:
- Write notes about action items
- Record instructions for complicated tasks
- Jot down what you’re doing at the end of the work day
- Put reminders in your path, physically and with technology
- Utilize search to find all of the above when needed
Your CEO has called a meeting to lay out their master plan. This is it, your chance to make a big impression and earn that promotion you want. You walk out of the meeting, pumped about this big opportunity, and suddenly it hits you:
You forgot half of what the CEO just said 😧
Bad memory is awful. Trust me, I get it. I’ve had bad memory for as long as I can remember, and the above scenario is my worst nightmare.
Over time, I’ve developed habits that compensate for my forgetfulness. Here are some habits that work for me and will hopefully help you too:
I know, it seems obvious, but seriously: write stuff down!! A lot of people (myself included) end up missing details while trying to write down too much. So what should you be writing down?
If somebody assigns you something or you tell a person “I’ll get back to you about that,” write a note that says what you owe them and when. You don’t need much - it can be as simple as a Jira ticket number that you can refer to later. One way or the other, notate your action items!
Documentation - the thing engineers love to read but hate to write. That’s why documentation is usually lacking, to say the least. But do yourself a favor: when somebody walks you through an undocumented process, write down the steps! Even if it’s just shorthand, make sure it’s enough that you could repeat the process a second time. Later, you can add more details and put your instructions somewhere official for your coworkers to use. Helpful little actions like this make you seem like a rock star, and it definitely helps your case for promotions and raises! 💵
It’s 5PM, you’ve been working on the same problem for hours, and you’re “this close to finishing!” If you’ve been here before, you know that you will probably A) keep working on it all night and B) not make much progress. For the sake of your mental health and for your productivity: please, stop doing that!
Instead, write a little note to yourself. Make a habit of it, even when you’re not in the middle of something intense. Stop right at quitting time, save your code, then write down things like:
This can be very brief. It only needs to be enough to get you back on task when you return the next day. I’ve been doing this for a while now, I’ve noticed something uncanny. I usually wake up the next morning and immediately figure out the thing that had me blocked the day before. That’s a subject for another blog post, but something magical happens when you get a good night’s rest.
So far you’re creating a lot of notes, but they aren’t much good if you don’t do anything with them! This is where reminders come into play.
People put their grocery list on their fridge because they’ll see it without having to remember to look for it. You can do the same thing with your notes and reminders.
That end-of-day note you leave yourself? Place it on your keyboard so you can’t miss it! Put sticky notes on you monitor. Sandwich important papers into your closed laptop. Make the important things unavoidable so you aren’t relying on your memory!
Physical reminders are a hardware solution, but there are software solutions that serve the same purpose. I know some people love the tactile feel of paper, but a paper calendar can’t send you a push notifications! Put important dates in a calendar app. When you do, make sure to set a notification so your phone will alert you even if you don’t look at the calendar app!
I’ve been using Todoist for a while now, and it lets you set dates for your TODO items. If you tend to make a giant TODO list and do none of it, it’s perfect. You can quickly assign due dates in Todoist by putting text like “next Tuesday” in the TODO item. Todoist then shows you the tasks due just today which makes it more likely that you actually do each thing!
Amazon is constantly running deals on their smaller smart speaker, the Echo Dot#ad, and I may have a bit of a shopping problem 😅. Over time, I have bought enough to have a smart speaker in every room, and I use them extensively for reminders.
They remind my kids to leave in time to catch the bus. They tell me when to take my vitamins. They are constantly blasting out little reminders that I have set up. Any time I think “I better do that thing tomorrow,” I holler at the nearest smart speaker and set a reminder. Don’t have a smart speaker? Use Siri or Google Assistant on your phone to do the same thing! A quick “Hey Google, remind me every morning at 9 to do XYZ” and you’re all set.
Alright, you’re in a meeting and you take notes. Easy. You’re completing a tricky, undocumented task and you document it. Makes sense. Now you’re in a one-on-one, verbal conversation with a coworker. What now?!
A little bit of honesty goes a long way. Don’t hide your bad memory - let everybody know. Say “Sorry, I’ll forget this if I don’t write it down!” as you whip your phone out. Instead of looking rude, people will appreciate your intent to help them out.
Another favorite of mine is to tell people I have bad memory and ask them to send me things in writing. Have you ever said “just text me the address” when somebody was giving you directions? Do that sort of thing at work. If somebody asked you to do something during a meeting, ask them to pull their phone out and email/text what they needed and when they need it. It puts a tiny bit of work on them, but I’ve found that most people will gladly send a text since it makes it more likely they will get what they need.
This may seem weird to you, but consider emailing yourself. When I suddenly remember something for work at 9pm, I send a quick email to my work address. I don’t even write a body to the email, I just put something like “Don’t forget about XYZ” in the subject line. The next day I sit down at work and see an email (okay, usually several) from myself. Oh yeah, I need to do XYZ! Works like a charm!
If you’re keeping track, you’re probably thinking that all of the above is going to generate a ton of notes. You’re not wrong.
Two things: 1) You don’t have to do everything above. These are the things that work for me, and you may have better memory than me and only need a couple of them. 2) If you did all of the above on paper it’d be overwhelming, but we live in the future, folks!
Pretty much any Google product is searchable. I have notes in Keep, Drive, and Gmail - all three of which are easily searchable. If you’re deliberate about how you write your notes, they can become really easy to find. As in code, I write TODO in my notes so I can search for “TODO” and quickly get tasks I may have forgotten. In Gmail, you can enter searches like from:personalemail@gmail.com to:workemail@work.com to find those reminder emails you sent - better yet, you can save that search as a filter for later!
As your pile of notes grows, it becomes more and more important to get good at searching. Put some effort into how you phrase your notes and keep that in mind when searching. The one thing I do commit to memory is how I write notes, so I can quickly find anything I’ve written via search.
Don’t let bad memory hold you back. We’re living in some sci-fi futuristic times, and there’s enough technology around you that you can use as a second brain. Computers are way better at remembering things so you don’t have!
]]>