This is part of the Peer Pressure Learning 30 series. Take a gander at my introduction to the experiment.

Thanks to Miles’ example, I’ve included the above note on each of my posts, just in case you have no idea what all this PPL nonsense is about. On to today’s work…

Functions (method) represent the core to almost everything we do, so I spent some extra time in this chapter. The last few pages were pretty light and included a rather long code sample.

It was striking just how small each of the methods in the example class were, with most being only one or two lines. The amazing thing was, while the class only had two public methods, there were probably 20 private methods. You’d think that would be a PITA to work through and dig around…but everything was so simplistic that even though it was Java code, I could read and understand it easily. The “pre-refactor” example code was around 45 lines, but was really tough to grok. Despite doubling the amount of code, it was a drastic improvement.

Today’s reading: pg 47 – pg 52

This daily rhythm of reading and looking over some code already begins to feel like a habit. I know I’ve said this a ton already. I’d really encourage you to consider some type of similar habit. Do something each day, even if it’s just 10-15 minutes. Make it consistent and do it all week long. Certainly, my test will come on Saturday and Sunday while at home. The kids will probably be up early and going crazy around me. But what better thing for them to see than their father taking his craft seriously enough to spend a few minutes on the weekend.

There wasn’t much text at the end of this chapter, but several key concepts still hit home:

• When you think methods are too small, shrink them a bit more – It was pretty amazing the effect of having 2-3 methods in the code sample. The whole thing read extremely well, and because everything within a method was at one level of abstraction, you got to choose how far down the rabbit hole you wanted to go. I could have read the first public method and understood what the whole class did. Reading two layers further uncovered more detail. I suppose it helps that I’m a hierarchical thinker, so the breakdown essentially helped show me the structure.
• Break things down! – By making everything into smaller and smaller pieces, simplicity follows. Don’t be afraid to break out more classes and methods!

I started tinkering with a toy project, “Should I STFU?” It will analyze a user’s recent tweets and give each one an arbitrary annoyance score, letting them know, on the whole, whether they need to STFU. It’s totally a gag and something fun to work on. I posted the source code so you’re welcome to submit pull requests with fun new point values (once it’s ready)!

This is part of the Peer Pressure Learning 30 series. Take a gander at my introduction to the experiment.

I didn’t make it as far as I planned as the material is pretty meaty in this section and really bears some time to review carefully. Having wrapped up function structure yesterday, this reading focused on function (method for the Rubyists in the crowd) arguments.

Today’s reading: pg 40 – pg 47

The general focus was on keeping argument lists short, which can come as a byproduct of having short methods that only do one thing. The author points out that zero or one argument are ideal, two being reasonable, and three or more becoming especially tricky. His point about many arguments making for painful testing was especially weighty given the propensity towards TDD these days.

A couple big pointers jumped out at me:

• Bury exception handling in its own method – This was somewhat strange at first (especially given that much of the Ruby code I’ve seen happily inlines begin/rescue). But the more I looked at the example, the more sense it made. I may try to do something like this next time I need an exception block.
• Separate ‘asking’ and ‘doing’ – Since a method should do only one thing, don’t allow your methods to answer something and also do something. The text calls this concept, “command query separation”.

It amazes me how short all the methods are in the examples. While reading the code does require jumping to various methods to really dig into how everything works. But, the naming is so good and the functions so succinct that often the name is enough to explain what’s going on.

Sadly, I haven’t gotten on the path of looking at 2 code smells each day. Perhaps that will find its way into my daily routine each Friday. Who knows.

In just a few days, I’ve already gained a lot of value reading and going over these concepts. I’d encourage you to spend some time each day learning something new to benefit yourself and your craft!

For those of you who are following along at home, take a peek at Miles’ Day 2 post on Riak!

This is part of the Peer Pressure Learning 30 series. Take a gander at my introduction to the experiment.

Today began with the first portion of Chapter 3: Functions from Clean Code. I stopped just before getting into function arguments.

Today’s reading: pg 31 – pg 40

The first section followed a consistent theme, pounding away at making your functions short, focused, and one-dimensional. My key takeaways were:

• Keep ‘em REALLY short – This usually isn’t much of a problem for me, right up until it is. At times, I get lazy (usually when not doing TDD) and let a function get out of hand. It’s crazy, as a longer function is a pain in the ass to test, and confuses the hell out of your future self. While the authors don’t give a hard and fast rule (which would be stupid), it appears that anything over 5-10 lines is likely a code smell.
• Do only one thing – Again, I feel like I generally do well with this, perhaps erring on the side of creating too many functions. I’m consistently challenged for creating too many rabbit-holes to dig through. I need to really keep any eye on this and put in the rabbit-holes where needed.
• Only one level of abstraction per function – I’m really excited about this one. While I’ve read Clean Code several times, this hasn’t sunk in until now. The idea is not to do string manipulation in the same function that’s doing SQL calls and building an HTML template string. It’s a somewhat nebulous concept for me to explain, but the book did a good job. I think it’s something you’ll recognize when you see it.

Tomorrow, more functions! It goes into argument counts and structure. Woot!

UPDATE: I got a bit too rowdy posting source code from a private project, so I pulled the exercise code. Definitely my bad. I may come back and do another exercise to post from one of my public repositories. More than likely, I’ll forget tomorrow.

This is part of the Peer Pressure Learning 30 series. Take a gander at my introduction to the experiment.

In the next 30 days, I’ll be reading Clean Code pg 17 to 284 (Chapter 2 – Chapter 16) as a part of our Peer Pressure Learning Experiment. That equates to about 9 pages each day.

Today’s reading: pg 17 – pg 30

Chapter 2 was just over the 9 pages planned and had a large code example, so I pressed through to finish the chapter. While I’ve read it several times (as I’ve tried to go through Code Complete in the last couple years), the importance of good naming may hold me to this chapter tomorrow as well for some further review. Key highlights include:

• A good name should reveal intent – A variable name like “days” is fine if only one thing in the function or class relates to days and the context makes it clear what the meaning is. Once there are more concepts, then you must expand the name to something like “elapsedTimeInDays” or “daysSinceLastClass”.
• Allow context to provide information – I struggle with balancing the context around a variable or function, frequently putting too much context into the variable name (making them rather long) when the code around it provides sufficient context. I’m quick to name a variable “customerAddress” when in the Customer class.
• The length of a name should correspond to the size of its scope – This was a really helpful distinction for me. I often use really long names, hoping to make the intent and meaning of everything really clear. Unfortunately, as my coworkers remind me, the long names can cloud the code and confuse things with too much information. Some of my issue is that I know too much about how a class/function will be used and code in that knowledge, breaking encapsulation and increasing coupling. Thankfully, TDD helps with this, but it’s still something I need to work on.
• Avoid mental mapping – This point made a ton of sense to me. Don’t make the person reading your code translate (map) one thing into something else. Single letter variable names are a great example of this. Even if you’re in an address function, it doesn’t make sense to use “a” for the address variable name. Your reader will constantly map “a” into “address” in their mind, increasing the juggling they have to do. I can see using single letter variable names in only in a few situations: 1) While using “i” for a loop index 2) A one-line block argument 3) Perhaps using “f” within a the form_for block of a view helper. That last one is still somewhat malodorous to me as the files are typically longer than a function and you have to map “f” to “form”. However, it’s used rather often and as it’s familiarity increases, the mental juggling declines.

Yep, if you didn’t already know, I’m a currently a Ruby guy. So, you’ll have to bear with me as all my examples will probably be Ruby code. And, I may not test all of it. The code above probably will execute, but I didn’t try it. You can be my tech editor. If you see an error, let me know and I’ll fix it.

Exercises

To make sure I really learn this stuff, I’ll endeavor to post some code changes I make as a result of what I’ve read.

UPDATE: I got a bit too rowdy posting source code from a private project, so I pulled the exercise code. Definitely my bad. I may come back and do another exercise to post from one of my public repositories. More than likely, I’ll forget tomorrow. Hopefully, the code samples moving forward will be enough to satisfy your desire to learn with me!

Despite being out of town for the weekend, I snuck away for a few moments to begin planning my part of the Peer Pressure Learning experiment. Below are my initial thoughts on spending 30 consecutive days studying and practicing Clean Code.

I was pleased to see that the text includes a Chapter (17) with just over 60 code smells. I’ll look to use those as part of the daily routine, attempting to write code that implements two each day.

When it comes to reading, I’m thinking that I’ll start by trying to do a certain number of pages each day. While that may break the book up into somewhat unnatural chunks, I figure that I can massage the sections each day to a more sensible length. I’ll post my reading plan as I go and perhaps organize it when I’m done.

The code-focused text begins with Chapter 2 (location 916 in the Kindle edition) and continues to Chapter 16 (ending at 7,091). Chapter 13 covers concurrency, which isn’t immediately relavant, so I’m going to skip it. So that leaves about 6,000 whatever-the-kindle-calls-them, or 200 per day. Once I’m in front of my print copy…I’ll get a sense of how many pages that is.

If you’re new to Clean Code, I’d recommend that you read through the introductory material, especially Chapter 1. Having written a book once, I can attest that the authors typically don’t put that stuff in there for nothing. I especially enjoyed the Introduction and its challenge towards hard work and sweat!

After a few weeks of talk, @mileszs (of Indy.rb fame) and I began getting our first significant peer pressure.

You see, we agreed to push each other to do 30 days of technology learning. Despite some great intentions and preliminary planning, we haven’t gotten anywhere. The Indy.rb group would have none of it and trashed us after the last meetup (which I happened to miss…boo).

And now we code

So here we are, on the verge of getting started! Our first day is Monday, June 14. I’ll be posting my progress via Don’t Break The Chain here: Peer Pressure Learning. I’ll probably try to put a calendar on the blog as well.

We’ve tweaked our concept a bit. While I had originally been jonesing to try a ton of new languages and technologies, that just isn’t relevant to where I’m at right now with my projects. That will probably change in a month or two. Right now, I have a ton of coding in front of me and mostly need to get more efficient and write better code. So I’m going to work through Clean Code in 30 days. I’m planning to break the book down into daily readings. For each one, I’ll do the reading, then refactor some code using the lessons learned. I’m told that if you act on (write, speak, etc) what you read, you’re significantly more likely to retain it. Ideally, I’ll posts a GitHub Gist each day with the before and after for critique.

As best I know, Miles plans to stick with the new technology path we originally talked about. I’m sure he’ll blog about his plan (poke, poke, Miles).

We’re thinking about using Tumblr to blog our experiences and document the journey and it looks like we can each run a separate blog that’s combined into a shared “Peer Pressure Learning” blog that aggregates both.

Going daily

I’m going to push for 30 days straight as I want this craft-building time to become a life-long habit. I’ve been told that by doing something 7 days a week, you’ll build a habit within a month. If you drop down to 6 days a week, it requires 60 days to form the habit. You need something like 150 days to make a habit when you only do something 5 days a week. Crazy, huh? Coding is a joy to me, so I don’t see a need to break from it over the weekend. Certainly, the projects I do at work need a break so I can freshen my mind and come back with new ideas. But for me, I’d like to see the practice of coding something every day become a reality.

I hope you consider doing something similar. Treat your profession as a craft and work at improving your skills every day! I’ve already talked to a few people who plan to join us. Get your blog on and I’ll link to your journey!

Acknowledgements

Special thanks are in order to David Eisinger who got our wheels turning with his post “Around ‘Hello World’ in 30 days”. It was a delightful read (as well as the related posts) and fueled our desire to do something similar.

I’m feeling inspired by the recent Smashing Magazine tribute to _Why and a tweet from Ray Hightower about another developer who blogged about his month of new technology. I want to challenge myself to do the same. It’s time to get back to creative exploration.

The last 3 months have seen almost every spare moment at home given to wrapping up open projects from the consulting business I closed down early this year so I could focus on my new job. It’s been a tough road, making sure that my leftover client work didn’t intrude on the workday.

I have 4 projects about 95% complete and a small site that’s 60% done. It looks likely that I can wrap them all up, Lord willing, by the middle of June. In that time, I will also give away what’s left of my hosting clients and may be done managing servers! That will finally leave time for fun and exploratory coding as well as putting in extra time at work now that we are hitting crunch time. I’m SO looking forward to no longer being pulled in a dozen directions.

Unlike my previous mode of building new web apps that could become subscription services, I’m planning to release all my stuff on GitHub (I just open sourced the code to Am I Down and will probably release my filtering Twitter Proxy this week). The practice and fun of creation are what i want most. The idea of adding a new business that im responsible for sounds awful.

The next few months will be great!

Since none of us exist as completely self-sufficient agrarians, we will all accept some form of compensation for the work we do. For most of us, that will come in the form of a check from our employer while some will pursue self-employment. Put simply, compensation represents the price tag for the work a person does.

After looking back on conversations I’ve had over the last several years, it’s clear to me that employees generally misunderstand compensation. I think that’s understandable as few have ever been in a position to set someone’s pay.

I think we have a responsibility to ourselves to build a strong understanding of compensation. I’m convinced that it will help us establish contentment and apply our effort properly towards accomplishing our goals. Be honest, you’d be happy if you knew you were paid exactly right. And you’d love knowing how your compensation was set so you could do something about it.

Summary

Not sure you can make it through this whole article? I’ve summarized the critical bits:

• Business owners hire employees to make profit for them
• Compensation has nothing to do with a person’s worth
• Two things determine how much an owner will pay an employee: The market and the company’s financial situation.
• The market decides how much an employer will have to pay for certain work. It’s the economics of supply and demand.
• When the number of people who can do certain work goes up, the price employers will pay goes down.
• If there are fewer people available to do certain work, the employer will have to pay more.
• If the company cannot afford the market rate, it must offer less to employees. Special circumstances may encourage an employee to accept less than the market rate. Otherwise, the business will live with an unfilled positon until the market rate comes down, or finances improve.
• A business owner is free to ignore the market and pay whatever they want (more or less). It’s their business and they can do whatever they want with it.

You cannot determine how much to compensate a person for a given position without careful evaluation of what the market will bear. Anything else would be guessing.

Market rate for a position can generally be determined by a careful analysis of:

• How much would I have to pay a replacement to fill a position

• What would a non-competitor pay one of my employees currently in the position

  Read the rest of this entry »

UPDATE (7:21pm):So…I find out that RVM symlinks into .gem/, so deleting completely may have been a bad idea. But…I was able to do “rvm reload” and “rvm update –head” that seem to have restored the symlinks I broke in the process. Life is good again.

While trying to install the latest Rails3 beta, I was beating my head against the following error:

ERROR: While executing gem ... (ArgumentError) marshal data too short

I’m running RVM and despite attempts to run “gem install rails –pre” on various ruby versions, every time I got the some error.

After bruising my head against nearby objects for a while, I found a small reference on a blog about gems in ~/.gem. After wiping them out, everything worked great! In the process, I blew away /usr/local/ copies of the gems as well (so your mileage may vary).

I’ve always been fascinated with creating a proper and efficient working environment. I’ve taken a fair bit of inspiration from the terrific writeup and gallery put together by Mitch Haile on his setup. Key takeaways:

• Have separate coding and administrative areas
• For coding, screen real estate is king
• Bush Series C office furniture rocks
• Ergotron makes fantastic monitor/laptop mounts
• I’m not a freak for owning/buying tons of books (in paper form, either)

During my 5-year stint at a local cabinet shop, I had enjoyed the opportunity to design and install two completely different office setups; one standing-height workstation and the other a traditional L. When I started Literacy5 a year and a half ago, I went through a variety of setups before I settled on something I really liked (some through necessity, and others out of a need to experiment).

Separate coding and administrative spaces

One of the most valuable lessons from reading Mitch’s office FAQ was the way he created different spaces for his coding and administrative/non-computer work. In my original office layout, I used the corner section to setup my Mac Pro and three 22″ screens. The large bowed section functioned as my admin area. This worked REALLY well. My computer workstation area stayed immaculately organized while the admin area was always strewn with papers. That gave me the ability to keep extremely focused on the work at hand while coding, with zero distractions. When working on the business side of things, I could multi-task and juggle whatever I needed. My Macbook accompanied my to the admin area whenever I did my bookkeeping.

I eventually swapped the admin/computer spaces to support pair programming. Two of us could easily sit side-by-side at the large bow-shaped desk and each have our laptops out. While I didn’t use it that way very often, it worked out great!

At work, I keep my desk space as sparse as possible, still maintaining as much screen real estate as possible. As an aside, the Kinesis Advantage Pro has made a huge difference in the trouble I was having with my wrists. It’s a topic for another post, but switching to Dvorak at the same time worked out nicely.

I really like having the two Dell 2209WA monitors on their side…it’s perfect for terminal windows, chat sessions, and Basecamp. The Macbook Pro runs the monitor on the left with the iMac 27″ handling the one on the right. With a little creative SSH action, the left 22″ can tail the Rails logs and it feels like you have three screens natively on the iMac.

Now that I spend the days at a shared office, my home office needs have changed dramatically. We are selling our 6,000 sq/ft home/office and will share office space with our friends John and Betsy at a converted warehouse. The office will primarily support managing our home, helping out with the non-profit we do accounting for, and my side projects. I may not even keep a computer there full-time, instead relying on my Macbook Pro. The new layout will still have two separate workspaces, but they will likely be split between my wife and I. I may even setup a dedicated podcast/screencast recording area so that I can leave my mic setup and ready to go.

Get a decent chair, please

One of the lessons I learned early was that a crappy chair can ruin your productivity (not to mention your back) by the end of the day. I’m a young guy, so I don’t care to complain about my back for at least another 20-30 years. The office I worked in before starting Literacy5 spent the bare minimum on chairs, so I’ve sat in some doozies. I never thought much of it since I was doing primarily IT support work with some programming sprinkled in. At most, I might be seated for 2 hours at a time with frequent breaks.

After a few more people were added to my staff, I spent considerably more time at my desk managing projects, coding, and handling server support. By this time, I was sitting in my chair for 7+ hours each day with only the occasional break. I realized just how important a decent chair (and having the sense to get up regularly to stretch) was.

So after launching out on my own, one of my major goals was to make sure that I got some decent seating. Like any new business, I didn’t have the stability to drop $1k on a chair right away, so I opted for a standing height work area…no chair needed! I build the desk myself and it worked great for quite some time. About six months in, I found that I was doing fewer meetings to attract new clients and had a lot more long stretches at my desk coding. While I really love a standing desk, I found that I couldn’t be comfortable more than 5-6 hours a day.

When I built a new office, I finally had the client work to justify a decent chair. I got a terrific deal on a top of the line Herman Miller Mirra through eBay, spending about $500. The Mirra is the follow on to the tremendous Aeron (I’ve tried both and prefer the Mirra). That has been the best $500 I ever spent. I’m sitting in it now and a year later it looks new, works perfect and still gives me 9-10 hours a day in perfect comfort.

Update: April 2010

I’ve had the opportunity to change my desk around, changing out a long 6ft table arrangement for an L-shaped workstation. It fits my monitor setup significantly better and affords a lot more space. I still stick to a clear work area, although it’s nice to have room for notebooks and printouts as needed.

I’m testing out the setup with only one 22″ Dell screen and thus far, it’s working fine. That will leave me with an extra monitor to leave at the other office where I was using only the Macbook. Having a second screen there will make a big impact.