Just be yourself. Strive to be your best self. Every day.

The only rival you should be trying to beat is yesterday's version of you. The only ideal person you should try to mimic is the best and truest to what's inside you that you can imagine yourself to be. 

Ultimately, you should be cultivating a conscious effort to seek the truth about yourself and your circumstances above the comfort of your status quo. Face your realities no matter how they feel.

Every time we step into a place of fear and the unknown, it's a chance to find out what we're really made of. Go forward with your instincts. You already know in your heart what's best for you, so get up, get out there, and do it.

Cover Letters

A friend recently asked me about writing cover letters for job applications. I told him a few of the standard pointers: be brief and get to the point, make sure you spell, capitalize, and hyphenate the company name right (I always look for the copyright on their web site), and be straight about where you are at on your career path. If you've got some weaknesses, point them out and immediately say what you're doing to work on them. If you're new to the industry, say so and show your enthusiasm, openness, and ability to adapt to new situations.

What it really boiled down to, in the end, was to just be yourself. Don't put on an act, don't hold on to an identity. Showcase the personality that you are actively cultivating for yourself. Match the tone and presence of the job description and company website, but with your own voice. If the company seems casual, act casual. If the company seems formal, add a little more professionalism into the mix. Either way, use your own voice, and your own style.

Don't fake it, and don't write what you think they want to hear. Remember that you're looking for a company that matches you as much as they want a match for them. If it's not a fit, it's not a fit. Move on and keep applying.

You Can't Be a Dick About It

One year when I lived in Chicago and had a live-in girlfriend, I bought us salsa lessons for Christmas. We went once a week and practiced (somewhat) regularly at home. It was a lot of fun and we loved dancing together. I felt cool learning something that looks complicated but is all based on simple, fundamental steps. Learning the basic step is like learning to ride a bike. You won't forget it. However, with more advanced techniques, "use it or lose it" is definitely true. 

When I moved to Montréal, one of my coworkers told me about a free beginner's night at a salsa club downtown, so I started going. Yep, had to take it back to the basics. I tried intermediate night once and I just couldn't keep up. It had been too long, I was out of practice, and so I stuck with beginner's night so it would still be fun, if not a little too easy. I didn't like that I couldn't remember the advanced stuff and my moves were pretty repetitive and boring. But all the same it was a fun activity to get out of the house and to take along a couple of friends who were true beginners.

During this lesson, everyone there forms a circle with an outer ring and an inner ring. The ring of men moves one person at a time, because salsa is a shared experience where you dance with different partners throughout the night. Well, one night, there was this girl in the "class" that my friends were saying was correcting them and making them feel like idiots. When I got to her, I had heard her criticizing the guys ahead of me, and I was nervous about messing up with her. Well it happened to me, too, she started snapping at me that I wasn't holding on firm enough, not pushing hard enough, not dancing with enough confidence, shit like that. It was really demoralizing. She wasn't pleasant to dance with, and I felt judged as a clueless moron, despite having some experience.

Unfortunately, I've found myself too many times being like the correcting, unpleasant girl in the salsa class. You're not testing enough! Your formatting isn't clean enough! There is no confidence in this code! No one wants to dance with that kind of partner. Leaders aren't made of dogmatic enforcement commanded down to others. It just makes people feel small, stupid, and clueless. This, in turn, would cause a cycle of me being chronically unsatisfied with my colleagues' work, and my colleagues not feeling any encouragement to advance themselves.

Yeah, I still think clean code and testing are important. SOLID is a great tool for thinking about your code. I believe in taking your time to review and revise your programmatic solutions for scalability and future maintenance. But what doesn't work, is being the overbearing corrector, the egocentric enforcer who makes their peers feel small and stupid. They won't want to grow, they won't want to work with you, and you won't see the change you want to see in your development culture.

It was never intentional. I'm sure the girl wasn't trying to be unpleasant. She wanted to have fun, too, and shy, limp-wristed dancers weren't fun for her. The only thing she knew to do about it was tell her partners the right answer. But it doesn't work that way. She may have had good intentions of wanting me and my friends to learn what to do, but all we got out of it was "dancing with this girl fucking sucks."

I still don't know what it takes to get others on board, but I know it won't happen through being a dick about it. If you're in the beginner class, then be kind to the beginners, and help them feel the fun so they're motivated to keep coming back. If you're too annoyed with the class, then maybe it's time to move on to the class where you belong. Advanced techniques will come with time, experience, and encouragement, not commands and enforcement. 

Now Learning EmberJS to Organize My Workouts

I'm working on a new app to help me organize and schedule my workout routines. It's at http://workouts.joesak.com - The code is being written in (so far untested) Ember and Rails at http://github.com/joemsak/workouts (ember client) and http://github.com/joemsak/workouts-api

I'm usually a TDD guy but since Ember is so new to me I find it's much more productive for me to learn it by trying to piece it together. Especially since I'm using Ember-CLI and all the tutorials, examples, guides, and general advice out there are completely different from one another. 

Not much else to say right now but hopefully there'll be updates and lessons learned along the way.

Time Spent, Wasted, Invested, and Saved

How long is two hours? How big is a block of two hours? Is time really shaped like a block? Is your first fresh hour in the morning the same length of time as the last hour of a long day? What exactly makes a day long, anyway? Hit the treadmill for five minutes. Now I’m giving you five minutes to fix a bug. Which five minutes will last longer?

We tend to treat time as if we understand it, as if we’ve wrangled it and confined it into neat little boxes. We’ve parceled time out into equal and measurable chunks in our planners and organizers. The impression of the clock misleads us into thinking that we could highlight a given slice anywhere on its face and it would always be treated equally.

There is a problem in software consulting, and that is the equation of units of time to units of labor. They do not share a 1 to 1 relationship, yet we surround ourselves with time-based estimates and contracts, we track our time in itemized hours, and measure this time spent on a given project. We conduct our work as if a linear relationship between the two exists.

Reports, estimates, and contracts certainly serve their purpose, but they too often distract us from the value of our talent, and refract our attitude about true productivity. Managers and developers alike begin to believe that the goal is to fit more tasks into less time. Or, similarly, if X amount of work can be done in six hours, then imagine how much could be done in two more hours. Never you mind the state of the developer’s mental energy after a solid six hours in the zone.

This is often mislabeled as efficiency and productivity. The mentality encouraged by these misomers is harmful to the developer, the product, the developer’s relationship to management, and the way clients think about the value of software. 

We should not merely be spending our time on tasks, squeezing a maximum completion rate per unit of time, but investing our time, as much as we can, into each task.

Douglas Rushkoff, an established media theorist, wrote about what he calls overwinding and spring-loading in his book, Present Shock, in 2013. 

Overwinding is the act of trying to load as much information into as little time as possible for rapid, instant gratification.

Spring-loading is the investment of time into a product or process, as preparation for future use. All of the time and quality invested is released upon execution in crucial moments.

An example Rushkoff gives in his book is about disaster relief teams that have fully equipped, pop-up medical facilities that they can deploy in hours, anywhere in the world, in the heat of a crisis.

So what are we doing to invest our time in our tasks? The primary value of software is its ability to change. Its secondary value is its ability to function according to customer specs.

Read that again. The primary value of software is its ability to change, not its completion to spec. Why? Because the spec is constantly changing.

It’s so easy to treat code as something we’ll just knock out, throw up on a server, mark ‘complete’ in a task manager, and move on, trusting those lines of code to go on and on forever doing what we wrote them to do.

As long as someone is using the software, then someone will ask for changes to it. We must be vigilant of our system design choices such that they can anticipate change.

There are lots of general, best practice guidelines out there. Acronyms like SOLID, CQS, SOA, DCI, and so on. They’re helpful strategies for identifying code smells and developing your own methods for pruning your code. It doesn’t matter so much which ones you like, or if you don’t care for any of them. The point is that you take the time to think about the impact and design of the code.

In crafts such as visual design, writing, photography, and film, the most important skill is editing. The artist removes everything they possibly can while preserving the message and artistic vision. This ought to be true of the code we write.

We should be striving to inspect our systems from different angles, to diligently remove or repair whatever isn’t contributing to effective communication. We can trust that sharpened editing skills will continue to serve us, even as all the subjective and trendy ideas about best practices shift from this to that.

Let us pack our time now, so that we may utilize it in spades later. When the class, module, method, or system that we write is unpacked–that is, executed at run time, implemented in the codebase, or when someone requests changes–we want all of that time and quality to spring back open for us.

The code opens up clearly, with guides and sign posts, maps, and well-driven trails for us to make our way. We took the time to use team-standard formatting, we followed established conventions (and we updated obsolete ones), our classes and functions have descriptive and useful names. The implementation is clear and does not force us to carry mental burdens about internal details. The system doesn’t resist us when it’s time to make changes.

However, if we have rushed through a handful of tasks, then the code that we produced will not spring open with much of any time, and we’ll find ourselves with no time left. We’ll be racing tight deadlines and staying late way past our usual work shift, chasing bug after bug, lost in a labyrinth of poorly communicated code.

If you’re committed to agile project management, but you’re not vigilant of long-term code management, then I urge you to question yourself why. Perhaps your first instinct is to say “better is the enemy of done.” Hey, I know the code can always be better, but are you really sure about when you’re done? How often does that ‘done’ code keep coming back to you to fix?

If you find yourself saying, “I don’t have the time for that,” take a second to look at your habits. People who use this excuse tend not to have very good habits. Instead of “maximizing efficiency” by completing tasks, maximize your efficiency of using better habits. As you grow, it will become second nature. I can promise you, that if you take your time, then you will always have the time.

Delete Your Code

In a recent blog post, Corey Haines suggests a novel approach to coding through short lived branches. Go check it out, Corey’s a good writer and a great programmer. The basic premise here is to treat your code like a daily sand mandala. You know that beautiful buddhist thing that they painstakingly create and then destroy every year? That. 

So, I gave this a try during my first week here at Elevator Up. Great first day move, right? Uh, yeah, yesterday? What did I work on? Well, I deleted it all.

Read more at Elevator Up

A Small Prayer

I have a personal boundary about public or otherwise corporate prayer. I believe it should be a private activity. But of course, as someone who follows the spirit of the law, I do make exceptions. I’ll tell a friend in private that they’re in my prayers, for example.

Tonight, as I sat waiting for my curry chicken and fried rice, I felt overwhelmed by the tragic events of today[the Charlie Hebdo attacks], all of the response to it, and how so many horrific events have transpired one after the other, how everyone is railing against 2014 as the shittiest year in current events, and just the weight of it all. The weight of this suffering world, and our collective anxiety over it, just laid heavy on my heart.

Read on at tumblr

Currently traveling: Montréal

Hello again to all of my readers. I am traveling to Montréal tomorrow and then I'll be back in the states in time for Thanksgiving. I'll be back online to add posts to my blog after that. I know you all will miss me very much, anxious to get updates to this feed. But just hold tight, have a very Thankful Thanksgiving, and I'll see you in the wintertime.

Make your projects easy to setup with shell scripts

Sometimes, a project can take a lot of work to get loaded onto your computer. There might be some pre-requisite libraries to install, some database creation and migration scripts to run, and other low-level setup that probably has to be done in a certain order to boot.

Luckily, as programmers, we can write shell scripts for our projects that others can use to set the project up easily. And of course they come in handy for ourselves when we find we're copying the project onto another workstation for whatever reason.

It's really quite trivial to write such a script. I keep mine in the bin/ folder as bin/setup. Others keep them in the script/ folder, but it really doesn't matter so long as you document it correctly in your README.

Here's a gist of one of my bin/setup files:

As you can see, it's pretty simple and only works on a system that supports homebrew, which I believe is only OS X. It could be modified, however, to check for other OS' and run different code. It's just shell script.

To make the file work, you'll have to set execute permissions on it like so:

$ chmod +x bin/setup

Then instruct your readers how to use it in a README:

It is quite handy to have such scripts in each of your projects. Even if the setup is simple and straightforward, it's great for the practice and to get into the habit of making them. It helps your work stand out, too, as others will appreciate you taking the time to make their work a little easier.

Currently Traveling: Los Angeles, San Francisco, Chicago

I'm on the road! Well, I was on the road. Now I'm in LA. I've been visiting friends and relaxing, taking time off in between contracts and job hunting. I'll be meeting a client in Orange County to demo their project that I recently finished, but other than that I'm not here on business.

I drove 2,400 miles here, visited a friend in Prescott, Arizona, and picked up hitchhikers who were from Montréal (a couple of blocks from my old apartment as it turns out). I hiked the Will Rogers State Historic Park the other day, and we're going up to the miracle tree and the hollywood sign tomorrow.

This coming weekend, I'll be going to San Francisco for a few days, hoping to meet up with friends there, and then heading back along the northern highways to Chicago. I'm staying there for a week-long interview and audition. After I return from Chicago, I've got plans to fly to Montréal to see my old roommate for his birthday. It's going to be quite a month!

Here are some photos from the trip:

Fulfilling the client's requirements is software's secondary value

I know that sounds strange, but bear with me. Software should absolutely do what your client paid for it to do, otherwise you won't stay in business for very long. But that is not the primary value of a working piece of software. The primary value of software is its ability to change.

This isn't an original idea on my part, it comes from Uncle Bob, a renowned veteran programmer who has lots of great advice for coding professionals. I don't mean to appeal to authority so much as give credit for the idea so that I may expound upon it without false pretenses. Not everyone likes Uncle Bob's advice, and maybe it's not for everyone. That's okay. It works out quite well for me. What follows is his idea, from my experience, in my own words.

The primary value of software is its ability to change. What do we mean when we adopt this premise? The fact is, as long as software is in use, someone will ask for changes to it. Long after the estimated budget is spent and the contract has been fulfilled, someone using your software will want it to change. We want to be able to make quick and easy changes, because that will take less time and cost less money. Developers will also be happier and more relaxed as they work in the code; they won't be fighting deadlines and constantly sweating it out for two hours past closing time.

This is why we practice clean coding, test-driven development, and refactoring the code's design. We strive to make the system easier to understand, and for its design to pop right out to other developers. Remember that 'other developers' includes ourselves three months after we last touched the code. To help other developers and ourselves in the future, it should just make sense where things fit and how things work. Well written unit tests, paired with carefully crafted production code, help us keep our systems simple, loosely coupled, and easy to change.

Making software easier to change takes diligence and discipline, and at first this seems like it adds time and too much effort. Maybe that is true early on when you're first trying things out. But it is worth all the extra effort and any homework you can do to practice it, and it does become second nature. It doesn't take long for it to kick in, either. Once you know how to recognize things, you recognize them quickly and often.

We can learn techniques that give us the ability to spot coding problems early on. Developers call this 'code smells.' We look for issues, or sniff out smells, such as duplicated knowledge, poorly named variables, functions that are too long, complex function signatures, awkward object instantiation procedures, and more.

An easy way to build momentum with diligence is to follow the Red, Green, Refactor TDD cycle. Start with a failing test (RED), write just enough production code to pass the test (GREEN), and then refactor (REFACTOR). We look for the smells early and often, and therefore we clean them up early and often. That way, we're always doing the refactors when refactoring is a small task, and not a large, daunting undertaking. Of course, big refactors will come along once a larger design emerges, but they will be easier to make because most things will fit and fall into place.

Another technique that works for me is to push my code to Github and proofread it there. Github is a great "read-only" editor for code. "Read-only" in quotes because you can edit files there, but for the most part you're just browsing the structure of the files and the code. About three or four times, I go over the components and tests that I have recently written. I slowly scroll up and down each file, making sure that what I wrote is sensible and easy to follow, and giving it the squint test. You literally squint your eyes and see if the shape and spacing of the code is elegant. I also review the tests to see if setting up and using the objects is simple and straight-forward, and doesn't expose too much internal knowledge.

Those are just a few ideas and techniques for keeping an eye on your code's ability to change. Software design is a subjective practice with some well-crafted general patterns and solutions for achieving conventional results. Maybe you have some of your own that work for you, and you should definitely write about them and share them. I certainly hope this has been helpful to anyone out there, and I hope it has shed some light on the mysteries of software craftsmanship.

Tmux. Quick introduction, learning resources, and a scripted session

Tmux is a great tool for development and for pairing, whether in-office or remote. Hell, the remote tools are just as useful when you're sitting next to each other. Okay, what is tmux? At its most basic level, it's a great way to stay on the keyboard while managing different windows and panes of editors, consoles, and other commandline utilities in one shared terminal session. An editor here, a server there, continuous integration, a console, and a shell. Sometimes in tab-like windows, sometimes in the same window in their own panes, right there with your text editor and console. Think of it like a jsfiddle screen.

I highly recommend you also try the 256 color iTerm and oh-my-zsh


Tmux makes it easy to use all my windows with a well of keyboard shortcuts, avoiding mouse use. You might think mouse use is no big deal, that it's a trivial bit of effort and time, but hey that does add up, and staying on the keyboard helps me keep my focus. The shortcuts give you great power at your fingertips, though, and fingertip speed trumps wrist, arm, and hand to mouse, back to keyboard speed. Personally, I enjoy development at fingertip speed and tmux has a pretty low barrier to entry on learning.

Setting up tmux is painless if you have homebrew installed.

Just use brew install tmux.

Pretty much every command is prefixed with the, well, prefix command, which is Ctrl+b. You can configure that. Mine is set to Ctrl+a, for example. From there you can open new windows, open new panes, switch your focus between windows and panes, rename them, detach sessions, close sessions, and more.

Two great books for learning tmux are tmux, and for remote pairing tools, Remote Pairing. Pretty easy to remember those titles, if you ask me.

In the tmux book, they recommend creating a bash script for your various tmux workstations. Here's one of mine. I just saved it to a file named 'jamby' in my home directory, I run ./jamby in terminal from my home directory, and my workstation is ready to go.

It sets up the first window for vim, the second window for the rails server (it runs git pull, bundle, and rake db:migrate on the current branch), and the third window left on the commandline prompt named git.

A slow developer is a faster developer

Has this ever happened to you? I know I'm still guilty of it from time to time. You're looking for a solution to your problem online, and you find a blog post or Stack Overflow solution that looks like it's got the answer. Then you scroll straight to the code examples, and you copy and paste it into your project.  You refresh the browser and tweak and fiddle with what you pasted until it works. Sometimes, it just doesn't work and you don't understand why. 'What the hell? They said this code fixes my problem!' What went wrong? 

You didn't read the blog post. You skipped the explanation. It turns out that the piece of code you copied requires some sort of prerequisite setting, or only applies in a given situation that is similar to the one you're having, but does not apply here. They provided a link to another solution, but you missed it. In a hurry to "just get it done," you've glossed over the information that could potentially teach you what you need to know about the nature of the problem. You've missed an opportunity to know better for next time.

Be more interested in the nature of your problem than the solution to it. This will make you a better developer. You'll recognize similar problems in the future and you'll have at least half an understanding of what to do when things go wrong again. When you find a potential solution to your problem, slow down and read everything on the page about it. A slower developer is a faster developer. A developer who takes the time to understand and to do a job well is a developer who has more time to get more things done.

I like to say, the developer who takes the time, has the time.

How is it that a slower developer is faster, and a developer who takes more time to research a problem will have more time to finish their tasks? You might be thinking that that makes no sense. A slower developer is faster and has more time for more tasks because they now understand more about what they're doing, and can act faster in the long-term. The developer who took the time to do the job well is not constantly putting out fires from the tasks they thought they had already completed. The educated programmer avoids common pitfalls and mistakes that keep others stuck playing whack-a-mole on the same tasks over and over again.

If you find a tutorial or documentation about how to integrate a third party service into your application, read the whole thing first without touching your code editor. If you want, feel free to play around in a console, but don't copy and paste a single line of the samples into your production code. Instead, get yourself familiar with the problem domain and how to use the service to suit the needs of your system. Once you feel like you have 40% of the information you need, start writing tests, and then write your own production code. The code in the tutorial isn't your code. It's an example. Your code should reflect the needs of your system.

Next time you're tempted to 'just get it done,' and copy and paste the samples, challenge yourself to stop, go slow, and write your own code.