November 06, 2019
Wired released an article covering what happened with with Uber killing a pedestrian and it is a sobering read. This case study should be required reading for software engineers and CS majors.
Working in the technology field there are exciting technologies and things that can be built but as engineers we are responsible for what we create. Reading through the article it’s hard to understand everything that went into the systems faulting but it’s clear it was a systemic engineering failure.
As engineers building large and safety critical systems there are numerous complexities and real guarantees are hard, that does not let you skip out. Safety is a requirement that does not get put second. Never forget that there are people on the other end of our algorithms.
Is zero pedestrian deaths by driverless cars possible, no? But there are preventable deaths and other algorithmic decisions going awry across our industry, yes. What are you doing to make sure the systems you build do not let this happen on your projects?
November 04, 2019
Working on a small team with lots to do, one thing I have been getting better at it is doing just enough. Finding the highest priority work is hard but once you find what to do you have to reduce the scope.
Instead of over building, build enough to unblock and make sure it is done well enought to last for the needs of the system. Once you have gotten that far there are a bunch of optimizations, refactors, better engineering, and more that could be done, DO NOT DO THEM.
You have what you need; get going on the next task after pushing all the cool ideas and future work plans into your project management system. You may end up needing them and you may end up needing something different or the first pass you complete works well enough for longer than expected.
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?