Blog

• Tips for Developing on a Bus

  October 22, 2018

  I recently took a trip back home from Boston to Philadelphia and had two 8 hour bus rides. On these bus rides I tried getting some development done and here’s some tips:

  1.) Don’t do it.

  That’s it folks, all I got. … Not really. I actually did get some development done but mostly I got administrative work and thinking done.

  Here are my real tips:

  1.) Be prepared to be disappointed with the internet.

  This should be a given but just in case you have never used bus WiFi and you saw the promise of free WiFi and rejoiced. Stop it right there. Bus WiFi is not fast, consistent or reliable. Definitely not a great environment if you need to be searching for answers or downloading and uploading code. The highlight of my bus WiFi experience was a git push that just hung.

  2.) Have offline docs and your dependencies installed.

  If you don’t have a development environment set up or some offline docs. I recommend you do that before the trip. On MacOS I use Dash, which lets me search across language and library documentation offline from Alfred. This is a great tool for fast offline lookup and covers many internet searches without requiring the connection.

  3.) Don’t plan on being super comfortable or focused.

  Another no-brainer but you aren’t going to be the most focused, comfortable or productive. This isn’t going to be an ideal development environment. People talking, sights going by, bumps and jostles, these and more contribute to a less than ideal deep work setting.

  You can still get work done though. To make things smoother you can start by bringing good noise isolating or cancelling headphones. Just like in an open office; a decent pair of headphones goes a long way in distancing yourself from the noise and commotion around you. Also fully charge your laptop ahead of time. You should have a power outlet but occasionally they don’t work and often they will not hold your charger without some continual force or pressure, especially if it’s the big bulky Mac charger. My charger fell out constantly; better to charge only when you need it. Why not start with a full charge?

  4.) Plan the right kind of work

  A good work plan is critical, if you don’t know what you need to work on or need to do exploring or research you will have trouble. The main development tasks that I had success working on included some refactoring and test writing. Everything I needed was already on my computer and writing tests is often more thinking and implementing than research.

  When planning bus work think about what requires little less internet or can be asynchronous. I had success doing the following:

  • Reviewing other’s pull requests.
  • Writing up feedback for people’s reviews.
  • Writing tests and replying and refactoring feedback on an existing feature I am working on.
  • Reflecting and writing up notes.
  • Writing this blog post.
  • Plan and organize calendar, notes, to-do’s, etc.

  5.) Enjoy the bus ride.

  Personally I love long bus rides. Though not the most appealing work environment; buses constrain you in ways that can be rewarding. Minimalist principles apply here where subtracting can really add to your focus. The constraints of an 8 hour low quality internet connection helps me get s*** done and reflect on things that I don’t always get too. I also love being on the move and working in new places and environments, it can be energizing and carries over to when you are back in the office or home.

  Overall just embrace the limitations and you can get a lot done; just don’t plan burning through a lot of bugs or releasing new features.

  ---

• Reading Archive

  October 06, 2018

  I started compiling a list of all the books I’ve read over the last few years. Looking to post my reviews and titles here. This list will be growing over time. I also don’t plan on stopping to post on Goodreads or BookBub but instead use this as the source of truth and syndicate my posts/notes/reviews to other sites.

  What are your methods of tracking and referencing books you’ve read?

  ---

• The Programmer's Computer

  August 21, 2018

  Mac, Windows, Linux. Everyone has an idea of what type of computer makes a developer. Social media is covered with pictures of 4k displays and brand new MacBooks. Technology sites are always talking about the newest computers and updated hardware. But these expensive laptops, monitors and desks are not what make a great developer’s computer. The programmer’s best computer is the one they have. Modern computers can handle most everything you throw at it and external displays are helpful but not necessary for programming.

  Before dropping hundreds to thousands on computer equipment, try to use what you have. It might not be as sexy or cool looking but it will work. If you are getting a new computer to start programming what is wrong with your current one? Windows and you want to get a Mac? Try dual booting Linux to get a more Mac like development environment without the price tag. Poor battery life? Try replacing the battery for much cheaper than a new laptop. Actually need a new computer? Buy it, just make sure you can afford it. Don’t buy a new laptop to become a developer or to improve, buy it because you need to replace your old one or you want it.

  This really is a message to myself, I’ve been eyeing new computers a lot recently. Even though I have an old working Thinkpad X1 Carbon, I just don’t like the keyboard layout. Do I need a new computer? No. Will I get a new one? Not yet.

  How about you? What is your computer situation? Do you unnecessarily consider upgrading your computer? Disagree on buying a new computer?

  ---

• Inefficiency

  July 25, 2018

  I received a recommendation to listen to this podcast episode from my brother. An interesting analysis of efficiency. As a tech worker it hit home. It covers origins of the definition of efficiency to how it’s used today. Efficiency by definition is the effectiveness of creating the output versus the input. Not everything can or should be measured and prioritized for efficiency but it’s become the end goal for many things. The podcast explains that efficiency describes how well you control a system but not the what you are working towards. The most efficient system isn’t always the best.

  This podcast was a call to slowing down and being a little inefficient. Not everything can be analyzed measured but are still valuable. When applying this to programming I think about taking time to unwind, think, and prioritize. Measuring productivity in lines of code is universally shamed and spending hours debugging an issue can also be ineffective. Sometimes the best option is to be (in)efficient and step away. When you come back refreshed you may be more efficient, and if not you took a break to enjoy life.

  If this interests you check out the podcast here: (in)Efficiency

  ---

• Evaluate Your Tools

  June 24, 2018

  How often do you take a step back and ask yourself if you are doing things the most efficiently? I am in a terminal a large part of my day; running tests, editing in Vim, running git commands, checking files, etc. Over the years I’ve built up shortcuts and workflows to keep me fast and focused on what I need done. But I still have lots to learn and sometimes it takes getting really annoyed with a repitious action before we finally realize there might be the a better way.

  The other day I discovered CTRL+W and CTRL+U for the first time. CTRL+W deletes the last word in the prompt. CTRL+U will clear the current line.

  Some other tips and tricks I have found helpful.

  • Use TAB to autocomplete commands/files etc.

  • Use CTRL+R to search previously entered commands.

  • You can repeat the last command you typed with !!, this is useful if you forget sudo, i.e. apt-get update can be re-run with sudo !!.

  • Want just the last arg you entered? Use !$. A good example of this typing ls ~/Documents/folder and then wanting to change to that directory. You can do this with cd $!.

  Am I missing any good shortcuts? This is your reminder to keep learning and evaluating your tools.

  ---

• Rails Conf 2018 Day 3

  April 19, 2018

  What a trip! By day three I was struggling after traveling, meeting tons of people and listening to more lectures than I’ve been in since college. Here are the notes from the final day.

  Keynote: Livable Code

  Speaker: Sarah Mei

  This was one of my favorite talks of the whole conference! A great perspective on programming with actionable takeaways. I ended up making it it’s own blog post here: Livable Code.

  Takeaways

  • Think of code as a house, keep it clean and organized but you live in it, so make sure you can live and be happy.

  ---

  Putting Rails in a Corner: Understanding Database Isolation

  Speaker: Emil Ong

  Notes

  Database commits have four isolation levels:

  1. Read Uncommited: no guarantees on reading data that won’t be rolled back.
  2. Read Committed: read may change during a transaction and will throw a “this changed” warning.
  3. Repeatable Read: if an update came through while reading then rolls back.
  4. Serializable: Transactions are completely isolated.

  Translating these isolation levels to be useful in Rails:

  • ActiveRecord allows setting the isolation level.
  • Read the data you are updating inside a transaction so that the db can throw the changed warnings.
  • Keep assumptions and transactions small.
  • AR Statement Invalid error has a cause field that can be inspected.

  ---

  Up and Down Again: A Migration’s Tale

  Speaker: Derek Prior

  Notes

  Walked through how migrations work under the hood. Rails 5 introduces compatibility migrations to ensure running migrations with a new version does not produce different results. Even with compatability layer not all migrations are reversible or will create the same results. This is best effort and there can be migration rot: when migrations that previously worked are no longer runnable because they are no longer valid.

  Active Record migrations use the adapter pattern to handle the differing connections to different databases. Each conecttor knows how to translate commands like add_column into the SQL statements the database understands. When rolling back a migration ActiveRecord will record the steps a migration did and reverse them, ie create_table -> drop_table

  Takeaways

  • Migrations that worked at the time might not be re-runnable.
  • With versioned migrations Rails make migrations easier to run after an upgrade.

  ---

  The Intelligence of Instinct

  Speaker: Emily Freeman

  Notes

  Talk was based around the System 1 and System 2 thinking that is described well in the book Thinking Fast and Slow. Fear is a natural instinct that is system 1 saying “something is wrong!”. It’s up to us to listen to it. As developers we don’t face life or death fear but instincts can still be useful. Something not sitting right in code or in the system? Check it out. You might be on to something. But remember that anxiety and fear are not the same thing.

  Takeaways

  • Learn to listen to your instincts a little, they are honed for quick pattern recognition. Why not dig and find if they are right?

  ---

  Don’t Settle for Poor Names (or for Poor Design)

  Speaker: Alistair McKinnell

  Notes

  Strive for ubiquitous language. Ubiquitous language is used by everyone on the team from product to designers to users to developers. If people can’t write, speak and program with the same language than communication issues are going to happen.

  Introduced the Simple Design Dynamo which is basically the diagram from here: A Model for Improving Names and comes from extreme programming practices. There are three stages:

  1. Have passing tests for code.
  2. See structure and improve the names.
  3. Abstract and remove duplication

  It’s a iterative cycle that can start in any stage but naming and code improves as the process is repeated. The complete working process looks like this:

  

  Takeaways

  • Don’t settle for poor naming.
  • Use ubiquitous language to prevent confusion.
  • Iterate naming and code on structuring, naming, and cleaning duplication.

  ---

  Tenderlove

  Speaker: Aaron Patterson aka Tenderlove

  Notes

  What a ridiculous talk. The topics covered many git puns, Twitter musings, cat poop tracking, toilet lid left up strobe lights, and Ruby performance, memory managemnt and profiling. Tenderlove doesn’t take himself too seriously but stilled ended up giving some insight between puns and jokes.

  Performance profiling is tricky. Aaron talked about when to use a sampling profiler and when to use an exact profiler. What you are trying to figure out determines the profiler to use. When it’s general performance and you need to know where time is being spent use a sampling profiler. This gives you statistical data without slowing down code. When the question is “how many” then you will need an exact profiler.

  Takeaways

  • Need to profile?
    • When asking “how many?” use Exact Profiler
    • When asking “how much?” use Sampling Profiler
  • Incredibly smart people are working hard to make other developers lives easier.

  ---