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?
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?
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
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+Ufor the first time.
CTRL+Wdeletes the last word in the prompt.
CTRL+Uwill clear the current line.
Some other tips and tricks I have found helpful.
TABto autocomplete commands/files etc.
CTRL+Rto search previously entered commands.
You can repeat the last command you typed with
!!, this is useful if you forget
apt-get updatecan be re-run with
Want just the last arg you entered? Use
!$. A good example of this typing
ls ~/Documents/folderand then wanting to change to that directory. You can do this with
Am I missing any good shortcuts? This is your reminder to keep learning and evaluating your tools.
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.
- 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
Database commits have four isolation levels:
- Read Uncommited: no guarantees on reading data that won’t be rolled back.
- Read Committed: read may change during a transaction and will throw a “this changed” warning.
- Repeatable Read: if an update came through while reading then rolls back.
- 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
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_columninto the SQL statements the database understands. When rolling back a migration ActiveRecord will record the steps a migration did and reverse them, ie
- 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
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.
- 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
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:
- Have passing tests for code.
- See structure and improve the names.
- 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:
- Don’t settle for poor naming.
- Use ubiquitous language to prevent confusion.
- Iterate naming and code on structuring, naming, and cleaning duplication.
Speaker: Aaron Patterson aka Tenderlove
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.
- 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.
April 19, 2018
This was originally an entry in my Rails Conf note series but this talk deserved it’s own post. Sarah Mei give a really insightful talk with a unique way to view software. I will attempt to summarize it here but I would recommend listening to the talk when it comes out.
Think of software as a creative and iterative process over a purely technical endeavour. The talk began talking about Conway’s Law: The structure of the system a team or organization builds will match their communication structure. This means messiness in communication will translate into messiness in the code base. Often software teams work as independent technical teams when they creative teams. Programming can be creative and the systems we build rely on communicating and novel solutions.
Software is regularly compared to architecture, but Sarah argues that this is wrong. Architecture has three well defined stages:
These three stages are handled by separate teams and require separate skills. Software used to be built like that, but not any more. Now we have libraries and frameworks that provide the structure. Instead we are living inside of these buildings that are the technologies we choose. These technologies give us the outline and walls with limitations and design choices we must live with or work around. We now focus on making our code livable.
Inside our “home” of code we need to create value and solve problems. Also the happiness that we feel depends on who we live in the code with. Everyone has their own quirks and habits, but together you work and live together. This living together in a house analogy was extended to hoarding and messiness. When you let laziness seep in, little decisions and messes compound until it’s an episode of Hoarders.
The answer to this isn’t to through out the house and start again, the same habits and behavior that made the mess will slowly creep in to the new system. To prevent this mess approach coding with the livable code mindset rules:
- Don’t make it worse.
- Improvement over consistency: but be sure to communicate the direction and goal.
- Inline everything: do the easy things instead of saying you’ll come back to it.
- Talk more about the code.
- Don’t always ask for permission, but be upfront with what you are doing
- Don’t ask for forgiveness
- Be open to feedback but don’t always listen
Code gets messy if care is not regulary cleaned and organized. Blog post and book sample code is comparable to staged homes. Those aren’t livable, just like the showrooms and photos of houses for sale hide the clutter and the things you actually need in a home. This analogy really resonated when she pulled up a photo of a bedroom on a house listing and picked apart how it wasn’t livable. No chargers on the end tables, no dresser, bed was on the floor to make the room feel spacious, etc. This is staged, just like overly abstracted code.
Modern software development is building and using generic components that together build a home, and we live there so keep it livable.
- Think of code as a home, it needs to be livable, you should organize and clean but a little mess is okay.
- Value continous improvement over consistency and correctness.
- Rewriting code will not prevent the next codebase from getting messy, instead fix the process.