Tim Urian

This is the 30th essay of my 30-day essay writing challenge!

For a large portion of my life I was consistent at almost nothing.

While self-teaching my way to becoming a software engineer, I learned a couple of strategies, and I wanted to share them here.

Streak Based Consistency

Do X for Y days.

It's a good formula.

This sort of consistency is good for rocketing through an initial learning curve, though I wouldn't recommend it as a long term strategy.

Here are my three rules for being successful with it:

Couple the action to something that happens every day.

As soon as I put my infant down to sleep I sit at my computer to write my essay.

The biggest struggle is arriving at a place to do your work.

Put aside expectations about the quality of your output

Streaks are built by doing the minimum and being surprised at what it adds up to.

Do not push hard

You know that feeling when you strain near the finish line?

Don't do that.

My unscientific explanation is that your subconscious remembers "Doing this thing hurts." and creates greater drag next time you try to do that activity.

Project Based Consistency

This is consistency for the long haul.

There is a skill you want to master or a body of work you want to complete, and you know that being consistent is the key to accomplishing your goal.

But, since there is no exact expectation of how you'll get there, you'll need some structure.

Begin with failure in mind: A ritual and net for beginning again.

I believe you can't form a habit without falling off of it three or four times.

The only question is: will you get back on track?

You need systems to catch that you've stopped, and a way to welcome yourself back without punishment.

Time Tracking

Being able to see how consistent you are breeds consistency.

Counterintuitively, you don't need to analyze it past "did I do this most days?".

For me, close to every day is easiest, but we are all different, and finding what makes you most productive is the most powerful strategy of all.

Much ink has been spilled singing the praises of publishing online every day.

I thought I knew what I was in for, but I was still surprised by some of what has happened while publishing for the last 30 days.

You'll start to write what's easiest, which is an interesting signal.

After 30 days you'll have a feel for when an idea will shape up quickly.

For me it often means that I've thought about a topic for a long time, or that I've stumbled on an exciting idea.

This essay should probably be written tomorrow, the last of my 30 day challenge... but I was excited, so I knew it would be easy.

You'll think more deeply about what is happening in your day-to-day life.

When you're writing every day you're always on the hunt for new topics.

Some of my best essays were written about ideas I was struggling with at work, or thoughts I was ruminating on during my day.

Things you discovered while writing will weave their way back into your life.

Unsurprisingly, you'll write the most about what is important to you.

You'll then be amazed how much clearer you are when you speak about those same topics.

To write about a topic you have to wrestle with it to put it in words others can understand. Apparently this pays dividends.

Eventually this feedback loop will influence what you choose to write about.

You'll begin to trust that you'll always find something to write about.

It won't always be a home run, but picking up the pen at this rate forces you to see that you could write about anything.

You'll get used to the crickets... which is a good thing!

Realizing that, for the most part, only a handful of people are skimming your writing gives you so much more freedom.

You stop spending time on marginal improvements to your essays and start thinking about how to impart value.

You'll get better at responding to emails and text messages

Don't know exactly why, but it's true.

Perhaps it is realizing the value of shipped words is so much higher than the value of words stuck in your head.

I'm glad I took this writing project on. I'm excited to take a break, but I'm also excited to write more (on a more lenient schedule)!

I sold reality TV shows. Then I stopped.

I started a biz that broke even. I shut it down.

I said I'd always rent. Now I'm a landlord.

I thought I'd be buried in LA. Now I live in Oregon.

... and I'm happier than ever.

The changes that occurred in my life from getting off of the track I was on have been hugely positive, and I'm thankful for all of them.

(Though, being friends with me must be like having whiplash.)

All of these life changes that must have seemed big from the outside had a pattern:

• The status quo of my life would seem off kilter for a while.

• An event would make me see that I wanted something different.

• I would immediately stop, and change tracks.

Cue the struggle and hard things necessitated by changing direction.

Of course I had doubts, but all of these things seemed risky not to do.

What if I never found the work I'm meant to do? What if I never found the best place for me to live?

All of these changes required me to stop.

• To stop being certain things.

• To stop identifying with certain aspects of my identity.

• To stop believing certain things.

So maybe ask yourself: Is there something I want to stop?

I shut my business down because an off-hand remark gave me permission. "You know... you don't need to keep doing that."

When you stop you will get to grow and change.

You can stop, and something new can take place.

"You know... you don't need to keep doing that."

Weekend getaways. The grown up version of sleep-overs.

Whenever I've rented a house with friends it's made for a memorable time.

All friend weekends are good, but here are things that make me particularly happy when they're in the mix:

Hot Tub

Are you really friends if you're not basting together like a bunch of hot dogs?

More space than you think you need

It's always tempting to save a few dollars and get a smaller place, but it's easier to overnight with your friends when you have ample elbow room.

Board games that are "Party Games"

I'm a nerd, and lots of my friends are nerds. And woah, do we love a long, complicated board game.

Unfortunately, we also love negronis. The two don't mix very well.

Bring games that everyone can get into, and that don't take up much brain power.

A personal favorite: Wavelength.

3 Ingredient Cocktail

Speaking of negronis!

I always feel a little more on-vacation with a cocktail than cracking open a beer.

Additionally, being the house bartender can make you very popular!

Epic Charcuterie Board

Nothing creates a familial atmosphere like meats and cheeses.

Bonus: Leftovers for snacks!

More sparkling water than you can even imagine

Staying hydrated is important, and with so many people in one house everyone forgets which water is theirs.

There is no amount that is too much.

A planned activity

This could be:

• A meal you dress up for

• A theme night

• A PowerPoint party (google it, it rocks!)

A meal plan that allows everyone to show off what they can cook

It's time for everyone to bring out their signature dish. I like when everyone gets to claim a meal.

Just don't forget to all bring snacks!

A late checkout

Despite best efforts, rolling out of a rented house always takes longer than it should. If you can, give yourself a buffer.

I'm excited for an upcoming holiday to Palm Springs! Let me know the key elements to your friend-cations in the comments.

Maintenance isn't sexy.

Someone who is "keeping things running" doesn't get many magazine articles written about them.

But, the more time I spend in my work, which is almost all maintenance, the more I come to believe that maintenance holds the key to so many things.

Maintenance is a kind of planning

Initially I thought maintenance was about living in the past, but it is really about tomorrow.

It's an investment you make in how you want things to be.

What do you want to not go wrong?

Sometimes things need to break a little so that you can learn how to make them a whole lot better.

Diving into a problem within a system can introduce you to that system's biggest bottleneck.

Incremental improvements can reveal large possibilities.

Owning things has a cost, so get rid of what doesn't serve you

All complicated objects require ongoing care.

The universe trends towards entropy, and whether it is time or money, keeping things working will cost you.

Your resources are limited: be careful what you choose to keep.

There is a corollary, if you want something to leave your life don't maintain it.

Consistency matters

It's easy to miss a couple of cycles of routine maintenance.

Reminders should rise to the level of urgency that the thing breaking would cause.

Making things uniform makes life easier

Socks are a great example.

If all of your socks are the same brand and color you don't need to spend time matching them up, and they become easier to replace.

Maintenance can make or break anything

Your health, your relationships, your city's sewage system - everything needs maintenance to keep working correctly.

So prioritize what is important to you and maintain it with care!

What could you accomplish if your whole engineering team was 1% more productive?

Too often we're hypnotized by shipping features or fixing bugs, activities that provide direct value to the customer.

Providing value to your fellow engineers has the potential to increase your whole organization's velocity.

Here are 10 places to start:

1. Enhance Speed

... of slow tests, deployments, development environments.

Nothing kills forward momentum like waiting!

2. Enhance Ease

... of getting setup or finding the resources you need.

Developers love automation, and smooth experiences keep them from being derailed.

3. Reduce External Dependencies

Can you use one library where you currently use two?

Is there something you could bring into your codebase instead of importing?

Eliminating dependencies can remove complexity from your code and reduce ongoing maintenance burden.

4. Keep Dependencies up-to-date

Keeping your versions near the most recent major release will put the best tools in the hands of all your developers.

5. Automate security measures

Too often security is an afterthought.

Automate some of the burden with tools like Snyk or Dependabot (which is also helpful for those upgrades!).

6. Increase Developer Happiness

Be the person who organizes a talk, or a hack-a-thon.

Work has an emotional component, and I believe we all work best when we are happy.

7. Decouple code

Tight coupling happens naturally, and before you know it the dependency graph of your code is a tangled ball of string.

Even minor refactors can help straighten things up and open code up to extension.

8. Decouple architecture

This might be a controversial measure, but pulling a feature out into it's own service can be just what the doctor ordered.

Especially if that feature has special database needs.

9. Increase adherence to standards

If your codebase has been around long enough you have multiple styles running through different eras of code.

Fixing up code style is one of my favorite "waiting for a meeting" tasks.

10. Share Knowledge

'Lunch and learns', posting interesting posts you've read in slack, or creating documentation are all great ways to make sure everyone is on the same page.

These are just a couple of ways that you can add value to your organization.

Features can get customers through the door, but I believe improving developer experience can create a sea change in the output of your organization.

You have a limited amount of time to spend on software maintenance.

It seems counterintuitive to spend it on things that aren't broken.

But the same libraries you use to get off the ground quickly can hold you back in the long term...

Often right when you need them the most.

A harder upgrade path when you need it

There's no wake up call like discovering a capability you need is within arm's reach.

All you need to do is upgrade one dependency...

That's when you find that you need to upgrade many dependencies to support that single upgrade.

This cost feels like a margin call on technical debt.

The things you depend on are more likely to change

I've encountered dependencies where:

• The exact version being relied on has been removed

• It is no longer maintained at all

• There is a ticking clock on upgrading

One of the principles of Object Oriented code applies here: rely on things that change less often then you.

Become out of step with your industry

It feels bad to work on code without the latest affordances.

You'll know that there is a simple solution a few major versions ahead in your framework, but the upgrade would be harder than accomplishing the task at hand.

All while your adding more costs to upgrading code.

Security

This may be the most obvious cost, but staying will behind on software dependencies can open your software up to vulnerabilities that would otherwise not worry you.

I don't advocate for riding the bleeding edge for the libraries your software depends on.

Upgrading regularly will keep your software nimble and safe, and your developers happier.

"It doesn't matter what language you start with."

Each time I read that on some blog I would grit my teeth. It's easy advice to give after you've learn a few programming languages.

When you're looking down the barrel of a couple hundred hours of learning, you need more info than that.

The way I see it there are two key components to the choice:

What is easy to learn and what is useful to learn.

Easy enough to not get in your way

When you're choosing your first language you aren't just trying to learn that language.

Want you really want to learn to solve problems with code.

The language you choose can help or hinder that process, even though it is only syntax.

Since you're learning to think in a new way it is best to choose a language that lets you focus on that.

Beware of languages that are known for being:

• Complex

• Verbose

• Strongly constrained

• Particularly difficult

"Easy" as in "easy to find answers"

Target a language with a large community and plenty of beginner material.

Where will you be able to turn if you need help? Forums? Friends? YouTube?

This is much more important than choosing a language that is new and hot.

"Useful" depends on your context

If you're targeting a certain role or company there may be a language that is the de-facto standard in that field. It's likely worth learning that language regardless of ease.

Otherwise, useful might mean hireable, or good at solving your problem.

What I would do if I was starting over

When in doubt go with the hits:

Python - My first lang! Learn this if you are looking to work with data. Ease of use is high, it's popular and there are tons of great learning materials.

JavaScript - It's everywhere. Learn this if you are interested in Front End Engineering. Immensely popular, not known for being easy but for having a huge community.

Ruby - A language built with developer happiness in mind. Clear, simply syntax. Also, closely tied to the excellent Rails web framework, which makes it a great choice for aspiring web engineers.

There is no wrong first language. Follow your interests, work consistently, and remember that what you're really learning is a new way of thinking. Eventually the syntax will take care of itself.

A learning path can keep you focused on gaining the skills that are important to you.

It's a simple, but powerful list of what you plan to learn and why.

Here are the questions I ask myself whenever I'm charting out the next six months of my path:

Where are you now?

A frank self-assessment will help you understand the foundation you're building on. Taking a step back, you'll be able to see your own strengths and weaknesses.

This is also a great point to get feedback from managers and mentors.

Knowing where you currently are can help others make useful recommendations.

Also, list materials have you already completed, and the obstacles that may stand in your way.

Where are you going?

Establish what topics you're hungry to learn.

What will success look like when you're done with this part of your path?

Is there a gap between what you're interested in and what is useful to you? If so, how do these relate to your goals in life?

Then you can get tactical by figuring out, at a high level, what topics you need to study.

What courses, books, and tutorials can act as stepping stones to get there?

This is the fun part: gathering the materials that will help you reach your goals.

There's a lot to say about this topic, but one recommendation is to look for ways to 'play the whole game' early on.

Let's say you're learning web development with Rails. First, you would find a tutorial that guides you through creating a toy app. Then you'd commit to a more detailed video course.

Getting a picture of the whole first helps you see how the details fit together.

Your mission should be to create a scaffold of learning that equips you to reach your goals.

I'm continually surprised that we're still dealing with this pandemic.

The most important aspect of a database is that it stores your data predictably.

With just one editor it's pretty easy to keep data in good shape: just apply the last change. However, databases are usually being accessed by many users, and concurrency causes things to get tricky.

Here are the main things you need to know in order to reason about database locks:

Record locking prevents simultaneous access to data

How do you make sure that multiple edits happening at almost the same instant have correct results?

You force them go one at a time.

Locks are applied to data for the duration of an update or delete making it so that only one transaction (think edit) can access them at a time.

Other transactions that are trying to edit that same data are put into a queue to wait their turn.

From here on out the way database locks are implemented is mostly fancier, more efficient versions of making transactions go one at a time.

These details are important to keep as little waiting as possible, but you don't need them to form a mental model!

"Deadlocks" are when two locks are waiting on each other

Let's say we have an antique book trading database.

I decide I want to give you a first edition "Grapes of Wrath" and you want to give me a beautifully illustrate copy of "Alice in Wonderland".

If we submit our requests simultaneously each of our accounts would get a lock, BUT both of those locks would stay infinitely because they are waiting on each other to complete in order to start.

The main solution to this situation is to abort one of the locks and let the other finish.

Locks can be applied on several different levels

• Database level locking - can't change anything anywhere

• Page level locking - lock an entire page for editing

• Row level locking - As granular as it gets, lock individual rows

• BONUS Application level locking: some databases allow you define your own locks.

These three pieces of knowledge should give you just enough to reason about database locks, and to google your way out of locking issues.

Nothing can get a team of engineers bikeshedding like discussing coding style.

Tabs or spaces? What should multi-line conditionals look like? What kind of quotes should we use and under what circumstances?

It might seem trivial, but there are some good reasons to choose a style guide (or create one as a team) and stick with it:

All code feels like your own

When I roll into code that is a mess formatting-wise (a fairly subjective measure!) I tend to judge it negatively, and when hunting for bugs I fixate on it.

After all, if the person who wrote it wasn't careful about formatting what else were they sloppy about?

Of course there's no law that says that poorly formatted code is any worse than other code. A strong style guide removes this issue completely, and keeps you from pre-judging code written by others.

Reduces cognitive overhead

Style is subjective, but long term, code is written to be read.

There are many valid styles, but sometimes hopping between files that are formatted differently can feel like reading a book where the format changes for each paragraph. Sure, you can read the book - but it is distracting.

Ideally the only thing you're thinking about when you're reading code is what it does.

Tidiness makes you feel good

For me, aesthetically pleasing code makes me feel happy. I bet that is the case for a lot of coders who take their craft seriously.

Would you prefer to work in a clean room or a cluttered one? A codebase is like a shared living space - everyone has to pitch in to keep things neat.

Ultimately I doubt that the style guide you choose matters very much, but there are compelling reasons for choosing one, and sticking with it!

When I am halfway finished working through a technical book I start longing to start the next one.

The beginnings of technical books are so much easier than the ends of them. There's so much promise in the introductions about what you'll be able to do if you can just cram all of this knowledge into your head.

However, as much as I always want to move on to the new, cool thing, there are huge benefits to picking up a book you've already read.

Gain a new perspective on skills you've been using.

When you're new to a concept you have to work hard to gain new knowledge.

Re-reading is easier.

When I take the time to do it I learn concepts I either misunderstood or missed completely. I find subtleties that only make sense now that I have been in the world working with the knowledge the book provided.

Take some of the pressure off of the first read.

On your first read through you don't know what points are fundamental principles, and which ones are tangential.

I used to drive myself crazy trying to master ever skill in every chapter. Knowing that an older, wiser, more experienced you is going to come back to this book eliminates the pressure to extract every morsel during the first reading.

Additionally, it's easier to understand a book when you know where it is heading.

Read books that are worth reading twice.

How precious is your time to you?

If you commit to reading a book twice you'll be more careful about the topics you read about, and the quality of materials you work with.

Do I re-read every single book I read? Absolutely not. However, I have gotten much more than I imagined out of re-reading books on fundamental topics, and I think it is an important tool in any programmer's toolbox.

While watching programming videos behind the dumpster during my lunch break at Trader Joe's I realized I had a problem:

Finishing projects is hard and time consuming.

When I was skilling up to become a software engineer I mainly used the Udacity platform. The best part of these courses was open ended projects with feedback.

However, I quickly learned that self-paced projects can balloon, both in time and complexity.

I find there are two strategies that are integral to taking these projects to completion:

Be willing to cut scope at any moment

"When you're 90% done you're 50% of the way there" is true for many projects.

The questions you have to ask yourself constantly are:

• Is this enough?

• Will I learn significantly more by doing more?

"Enough" is contextual, and depends on your goals, but I have often found myself going above and beyond for no extra reward when I had already gotten the experience I needed from the project.

The fastest way to finish is to ship what you've already got.

The right kind of to-do list is a project plan

I squeezed in much of my project work on the bus and on the weekend. I didn't have the time 'get in the groove.'

To make the most of your time you need a plan that gets you from start to finish. It must have bite-sized tasks, and capture where you left off.

A task has the right size if you can complete it in 30 minutes or less. It is motivating and efficient to move forward in smaller increments.

Your project plan should be constantly updated so that you know exactly what to do when you pick up this work again, taking needless decision-making out of the equation.

I'm a passionate autodidact, but too often my projects finish flat.

When people were first touting 'cohort based online courses' I thought it was a bit silly, since every class in school was 'cohort based'. I worried that a course being 'cohort based' might actually detract from what I love about online learning: it's asynchronous, the best lessons from the best professors crystallized.

Now I'm doing two cohort based courses simultaneously, and I love both of them.

Built in friends and energy

No one forces you to do an online course.

Gone are the days of unmotivated, uninterested classmates. The self selection that has already happened for people to embark on a course you're considering means that they share a passion with you, and are hyper motivated.

My favorite part about Ship 30 for 30 is the breakout rooms at the end of live sessions.

This might be the quarantine talking, but getting to hang with interesting people from all over the world was worth the entire price of the course.

Accountability

If I don't practice piano every day, the video I turn in to be reviewed will be bad.

I won't get in trouble, there is no grade, but I won't let it happen.

If I don't ship my essay for the day no one will even notice, but I'll still have to see everyone else's work in my timeline.

A Clear Path

Every day I sit down at the piano with a minute by minute checklist of what to do. The on-boarding for Ship 30 for 30 was similarly detailed.

I have a thousand things going on in my life, and being able to remove decisions from the learning equation has made it easy to stay on track. I simply set the time I'm going to do the work, the rest takes care of itself.

Cohort based learning is dynamic, constantly being stress tested and improved. I've become a convert, and I'm excited to participate in new communities.

I used see an error and groan, now I smile.

Why do beginning programmers rush past error messages? When you're new to programming, a lot of your code doesn't work. It seems easier to read your code and find the mistake instead of parsing an intimidating error message.

It's a bad habit, and one you should break early, because there's a better way.

Luckily, it is easy to understand these 'SOS' signals from your program. Here's how:

Read the whole message

That sounds silly, but how many times have you just passed your eyes over it? Some errors will be more clear than others, but don't just rush back to your code.

NoMethodError: undefined method `upcase!' for nil:NilClass

In Ruby the error has it's own class, in this case "NoMethodError". Then, it gives you a message that contains everything you need. It points out the name of that method that should have been defined, and the object it was expected on.

Go to exactly where the error occurred

The error will also come with a 'Traceback', which is a print out of the stack of calls that were made to get this error. The very top of that stack will have the number for the last line that was run.

test.rb:35:in 'cool_method': wrong number of arguments (given 1, expected 2)(ArgumentError)

In the above the error is saying "In the file test.rb, on line 35, while calling `cool_method' you sent the wrong number of arguments".

Simple enough here, but in sticky situations this line number will help you navigate quickly to the scene of the crime.

Remember the patterns you encounter

When you start paying attention to error messages you'll see the same ones over and over. You'll start to recognize the patterns that get you to the error and you'll start to defend against them in your code.

By doing these simple things you'll become a more efficient debugger and accelerate your journey to becoming a Ruby master.

The worst thing I can do at the beginning of a programming session is to close all my tabs.

It's a guarantee that I'm not about to start coding. When closing tabs I'm sure to find something that I should just "read right now and get out of the way". All of the sudden I've read several posts and my brain has been primed to seek novelty.

Not the state of flow I was looking for.

Luckily, this isn't my first rodeo. Here are a few off-the-beaten-path suggestions for getting in the programming zone:

Minimize all the windows you don't need

The digital equivalent of pushing everything on your desk to the ground.

Don't even look at what it is, just minimize it all.

Open new windows, start new terminal sessions. Give yourself the blank slate you would ideally have started with. With any luck your computer will crash at some point and you'll never have to face that mountain of blog posts.

A clear workspace is important for focus, this is the most efficient way to get there.

Listen to the same song on repeat

I'm sure this one makes me seem like a real psycho.

Choose a long song with no lyrics and set it to repeat. Classical or jazz works great. Time will fade into the background and distractions will disappear. If you notice the song starting over, turn on cross-fade so that it is seamless.

Focus happens when there is just enough going on to distract you from boredom, but not enough to overwhelm you.

When all else fails, pair up

Like it or not, focus has an emotional component.

When there is something bothering me, concentration becomes difficult. Usually getting out for a walk is the remedy, but when that fails I put out the bat signal for a pair programming session.

Pairing forces you to focus using social pressure. Plus, it's a great way to deepen relationships and be productive.

These are some of the weird ways I get myself to focus on doing what I love: programming. Let me know your tricks so I can add them to my toolbox!

If you want to change customer data for any reason a "quick script" can be disastrous.

When someone trusts you with their data they make you the keeper of their digital life. A hastily constructed bit of code can cause you to lose data, and your reputation.

Data mistakes can lead to:

• Bad data that bites you in the distant future

• Problems that affect the performance of your application

• Code being harder to ship and reason about

• Useless orphaned data that will never be cleaned up

When my script crashed halfway through the update I thought I was toast.

How did I not imagine this could happen? It wasn't even a flaw in my code, my remote session on the server dropped. How was I going to tell my manager?

After hours of tedious data manipulation my "quick fix" was finished with no loss of data or trust - but it was clear my workflow had to change.

Migrating and modifying live data is integral part of being a software engineer, and here are the two most important rules I use to do it safely:

Write scripts so that they can stop, be resumed, and be completely undone.

If I had known then what I know now I would have been disciplined in my script's ability to crash and resume.

Luckily, I had been sure to back up all critical data. Persisting your script's state, or logging work as it is done can make your script robust against interruption.

Programs like tmux and screen can keep your session alive on the remote server itself and provide another level of safety.

Have your 'one-off' scripts reviewed like any other code.

In software engineering careful beats quick every day of the year.

For non-trivial changes, create permanent, robust scripts that go through the review process. Bonus points for putting them in a shared repo so that future engineers can see what's been done.

Why forgo the benefits of peer review when faced with the high stakes changing data can represent?

With these two tweaks I've had:

• Less time spent fixing foot guns

• More trust in the integrity of the data I change

• Easier time identifying bugs

• And less stress at work!