October 15, 2019
Code reviews are super important for keeping track of changes, learning from team members and improving the quality of your code base. They take a lot of effort and can sometimes be hard to get right. I have compiled a list of things I like to keep in mind when prepping my code for review or doing a review of other’s work.
Some things to keep in mind when getting your code ready for review by others:
- Review your code with a fresh set of eyes before assigning some one else. I struggle to do this one sometimes but it’s a great thing to do to respect your teammate’s time and help you catch things too.
- Make sure to let your reviewer know expectations of what kind of feedback you need. If it’s just a draft and you want feedback on approach it will be different than a final review before shipping.
- Try to keep your changes small and atomic. Sometimes this can not be helped but when this happens try to chunk the review into pieces. I try to create commit chains that can be stepped through.
- Separate the code that you wrote from your ego as much as possible. This is hard to do and most people struggle to do this completely but it’s important that you realize getting feedback should not reflect on you as an individual entirely.
Things to think about when reviewing:
- Do not nitpick. Try to recognize when things are personal design opinions versus actual issues. If there are small stylistic suggestions, make clear that it is that and not an actual problem. I like to preface comments like these with
- Take your time. To do a good review it might take some digging and work on your end. I sometimes end up digging into documentation, sample code libraries and more before giving advice.
- Do not dismiss choices or make vague suggestions, instead be clear with the problem you see and try to make strides to fix the issue with an alternative name, library or example code.
- Be careful to balance your remarks with calling out things you like too. Remember there is a person on the other end with feelings.
Obviously these are not exhaustive lists, there a lot more things to consider but these are some of the big things I try to keep in mind when reviewing or publishing code to be reviewed.
October 14, 2019
An important way that I stay up on top of news that is important to me is through RSS feeds. RSS is old school tech that has been around since 1999. It’s an open standard that almost every blog and news site supports. I subscribe to a variety of professional news outlets, blog aggregators and individual bloggers.
There are a bunch of different RSS feed readers out there. Two of the big ones I’ve used are Newsblur and Feedly. They both let you browse sources to follow or add your own. I currently pay for Newsblur which though not as pretty as Feedly is more functional for my use case.
I group the blogs I follow by category. The main categories I have are:
- Science & Technology
- Software Leadership
If you are looking for some blogs to start following here are some of my recommendations:
- Derek Sivers: eclectic blog with entrepreneurship, tech, productivity and other random musings.
- Brandur: engineer at Stripe who does some great technical deep dives into Postgres, distributed systems, websockets and more.
- Julia Evans: a tech blog with a mix of technical tips, comics, career tips and more. Example great post: Get your work recognized: write a brag document
- Signal v. Noise: blog about company culture, tech, remote work, managing etc. Started by the people behind Basecamp
- Kalzumeus: Finance, banking, tech and entrepreneurship.
- Hayley E. Frerichs: not a tech blog but a dear friend of mine who writes fun zero waste tips and has creative bullet journals I drool over.
Any blog recommendations for me?
October 13, 2019
Over a year ago I found the now dated article: A Guide to Becoming a Full-Stack Developer in 2017 and it really bothered me,
Big lists of technologies to learn are intimidating and are overly prescriptive. When a new developer sees this they may think wow, there is way too much to know, I’ll never get there. But the truth is the path isn’t to check each item off a list one by one until we are a “Full-Stack Web Developer”. This ends up being gatekeeping with a giant requirements list. There is another way to become a developer, no matter the specialty, it involves writing code and developing skills incrementally.
Instead of a checklist of things to know, lets use a system to build up our skills. I will try to explain the path I used to become a developer and continue to use to grow as a developer. This path is not necessarily quick or easy, but most rewarding things are not. If you follow a similar path there won’t necessarily be an end. When choosing to become a developer, you are choosing to continue to learn and grow indefinitely.
Ignore the end goal of becoming a full-stack/iOS/back-end/AI/ML developer and instead start with a smaller goal. Check out: Forget About Setting Goals. Focus on This Instead. to see the reasoning behind this. The TLDR is that a goal isn’t focused on the how instead it’s focused on the end, a system is what gets you to the goal. For our goal of becoming a developer we shouldn’t focus on learning technology X or tool Y. Instead focus on what problems do I want to solve?
Step 1: Pick a Starting Point
Let’s start by finding something that motivated you to become a developer. Are you trying to start a business? Launch an app? Automate a tedious part of your job? For fun? Great make that your starting point. If you have a big idea try to find a smaller part that you can tackle.
Step 2: Research and Plan
Alright we have a starting point? An idea for a tool or a problem to solve. Let’s figure out what we need to build. This is an intimidating open ended step. This is where searching, books, and tutorials can really help. Almost never is someone solving and displaying the solution to the exact problem you have. Instead we need to collect pieces, understand what they doing and then modify them for what we need.
Step 3: Build
Alright we found an overview or a blog post that loosely is similar to what we want? Great. Often we can’t understand everything that is going on until we’ve worked and played with it ourselves. Instead of trying to understand every part let’s just start building. This means opening a text editor and your computer and working through examples, writing our own code, playing with libraries, etc.
This step is important, we need to start somewhere, and rarely ever will you find someone who knows the whole solution up front. Instead start with what we know, write code, design interfaces, play with a program until you find something you don’t know.
Step 4: Define a New Goal
Once you hit a road block or are unsure of how to proceed we need to create a new goal. Can we skip or work around this issue for now? No. Okay, let’s figure out what we need to learn or know next.
Step 5: Iterate
Nice work, by hitting step 5 you already made some progress towards your goal. You now know what you need to work on or solve next. Time to repeat the process. These steps get repeated hundreds of times a day by developers everywhere. It’s a never ending process. Jump back to step 2 now with your new goal.
This method relies on just in time learning. Act until you hit a point where you need to learn more to continue, learn that and then complete it. When we try going the other direction and learning everything before action we very easily end up lost or misdirected. There is an overwhelming amount of things to know in almost every field. Computers are incredibly complex and we fool ourselves if we think we can understand it all before starting. The best thing you can do is just start this process today.
June 30, 2019
This is a fun little project I built this winter and I haven’t shown off here yet. I have been itching to build a home server for a media center, network attached storage and general nerd playground. One weekend I dragged Michelle to Micro Center and grab threw together a pretty decent server for under $400.
For the people looking for specs:
Case: Cooler Master Elite
Processor: AMD Ryzen 3 2200G
Storage: 120GB SSD + 2TB Hard Drive
Over all it’s a relatively performant box to run as a Linux server. I really dig the compact case and my only gripe was the noisy stock fans, but I replaced them for $25 and have not been able to hear it since.
I have already gotten a chance to do projects with it:
- Backup Hub: I set up all my laptops and desktops to backup to Cantaloupe and then it backs up to remote locations.
- Git Mirror: I wrote a simple Ruby CLI tool Crow to grab all code repositories and download them to local for backups.
- Private Git Repos: Git works over plain SSH so I set up a git user with repositories for code I don’t want to put on other servers.
- Plex Server: I set up my movies and music to be available locally on the network, next stop accessing outside my home network.
Anything else fun I should do with it? Would you have built it differently?
February 11, 2019
I read this article Compounding Knowledge from Farnam Street and enjoyed it. The article talks about lifetime learning and figuring out what to learn. There is a ton of information out there and it is not all correct or tested. How do you pick what to read and learn? Tons of smart people have different answers, some only read books published at least 10 years ago, others read no news. Can we apply a similar principle to help us keep up in technology?
In the fast moving programming world Hacker News has new frameworks and technology daily, but can we can find knowledge and patterns with longer half lifes. Technology is infamous for being fast moving and constantly changing but as things change, a lot does not. Skills and technologies you can learn that will be compounding knowledge:
- Debugging programs and systems
- Editing and reading text.
- Managing text
- Managing, storing and accessing data
Do you write perfect code the first time? Do you only use other code that is perfect? Probably not. For most of us, things will go wrong. How we handle when things do not work is a transferrable skill that will not stop being useful.
Learning to break down what is happening, validating assumptions, and inspecting components that are not how you expected are the basics of debugging. Of course there are multitudes of debugging tools that can help and pieces to learn about but these come with time and experience. To start on the debugging path you just need to print output from your program.
Pages could and have been written on debugging but one other thing to learn is to not be afraid to jump into code you use. Sometimes your code will be correct but a library, language or even operating system will be effecting your code.
These debugging skills can probably even help you outside of computers!
The year is 2019, text is so 1970’s, when you need to program you hop into VR and … open up a text editor.
Yeah, when you need to program you open up a text editor, that same tool that’s been around for decades. Emacs and Vi were both initally released 43 years ago. People still use these tools today! Of course since then we have gotten a lot more editors and IDE’s but in 43 years we have still rely on reading and editing text.
Editor wars have flamed on for decades and the fires will burn for decades more. People love to tie their programming identities and credentials to being able to use a particular editor, it really does not matter which though, pick a text editor and get good at using it. Using a text editor well will not stop being useful anytime soon.
As a programmer we are not just editing text; we need to view, search, track changes, build a mental map of how things work, etc. To help you do this there are a tools that will pay dividends long term, pick some and practice using them.
What was this function doing when it worked? What did it use to do? These are important questions that will help you if you know the answer to. If you use version control for your source code you should be able to find that out. Knowing how to use and track changes like this is useful almost daily.
Once you are working in an established code base or on a team with other members there will be code that you have not seen before or that you have not read in a while. You are going to need to figure out what is going on in the code. If you learn to search and jump around with your editor or the command line you can jump into new projects and languages easier.
If you want to learn how to use the command line for managing text here are useful tools start: moving files (
mv), removing files (
rm), searching for text (
grep), end of a file (
tail), and word or line count (
wc). There are a bunch more but if you start here you can dig in and learn more.
Once code is written it starts to rot. Not literally but your brain will decide to forget details on exactly why you wrote what you did and the programming library, API or language you use will update and your code will no longer work correctly. Sometimes the code works great but it needs to change because your requirements changed.
How do we know what still works and what changed or broke? If you move a bunch of code around does it still work? Of course you will manually run it and check that it compiles or looks right but how do you know? You don’t. Verifying code is important and comes from having automated testing.
Knowing how, what, when and where to test code is a really important skill that translates well across all programming and I would qualify as compounding knowledge. Writing testing this will also help guide design decisions and help your code last longer so you can solve new problems, not old ones.
Managing, Storing and Accessing Data
Databases and data storage are a huge component of nearly every software project. Understanding what your project needs for data storage and then implementing it correctly is an important task. If you use the wrong tool or the right tool in the wrong way your project can be technically awesome still a failure.
Databases can get complex; understanding the access patterns you need, the tradeoffs between database types, using caches correctly, and more will come with experience. To get started though a good place to start is to pick up a skill that is still being used 45 years after it appeared: SQL.
SQL is a programming language for defining, accessing and processing data from databases. It is used today by almost every technology company in some aspect and the fundamentals generalize well to other databases and technologies.
Improving your ability to learn is going to continue to help no matter what happens next in your career or in programming. Technology is constantly changing but if you continue to focus on improving your ability to learn while adding some knowledge that sticks for the next round you will have success.
You do not have to learn every new technology or framework, instead focus on the problems you want to solve and try to learn what the tools are doing to solve those problems. Learn the problem’s details and what you need is useful and will save you a lot of time and can enable super powers of getting stuff done.
Identifying what you do not know, understanding how to learn that and then discerning what you need and do not is a valuable learning skill will come back over and over again.
January 20, 2019
One thing I struggle with is seeking validation. As a relatively normal human I am often seeking recognition that my emotions, thoughts and observations are legitimate. I seek validation that what I do is meaningful, that people care about what me, etc. There are two sources of this validation, internal and external and most of us are driven and receive mostly external validation.
Companies across the internet and off all know this, they feed off external validation. Validation that we are part of a group sells lifestyles, apparel, vacations and more. Social media feeds a huge validation addiction allowing people to broadcast thoughts and moments to the world, and with a simple like, view or retweet we get a tiny burst of validation
There is nothing inherently wrong with external validation. It’s a powerful motivator that we all need. A problem I see is that when we get a lot of this cheap external validation we struggle to develop and strengthen our internal self. The “I am doing this because I want to”, “These are my thoughts”, and “this is me” feelings do not come as easily from external sources as they do from reflection, purposeful work with trial and error and feedback.
Feedback? “But Aaron, that sounds external?” It may or may not be but I see a difference here. Feedback is an active form of validation and nothing says it is purely positive. Constructive feedback, thoughtful recognition of emotions or views and suggestions on ways to improve the self are more valuable then a simple like, retweet, or simple comment.
So here is is my call for you to validate me. Not with a like or a retweet but with feedback, thoughtful comments, critiques, criticisms and acknowledgement. I will not always get validation externally. But when I do I hope it can be meaningful or actionable.
What am I doing to limit external validation and improve internal validation?
- Posting less on platforms that optimize for self validation
- Turning off tracking and metrics on this blog
I have been posting very little directly on Facebook, Instagram, and Twitter. Instead I contact people directly or post on micro.blog. What does microblog do different? No retweets, visible followers or visible likes. Anything I post on there is mine and there is social validation but it is respectful and thoughtful.
Turning off metrics on blog allows me to ignore the “do people like this?” and enable “do I like this” I am writing for me. Of course I want validation but I want the majority to come from me. If I really make an impact or you have any feedback I would love to know but likes and retweets and page views are distractions and not important
I think this stance is a little radical but it has been valuable to me. I have been reflecting and tweaking my goals and habits, making sure they come from the self. Want to validate me? Do it if you want. If you do not validate me that is fine because have already validated myself.