Daily Software Development

I’m not exactly silent in my belief that pair programming will help our industry, so it should come as no surprise that Steve Smith and I paired together on a Pluralsight course on Pair Programming. It only made sense to me that a course on pair programming would be created by two people. We shared the work on each module of the course, and we think it turned out well.

In the course, we cover the theory, practice, benefits, technique, and research of pair programming. From this, we’re trying to make sure that people both know how to pair program effectively and know why it could benefit their team. If you or someone you know has heard of pair programming, I’d recommend watching the course.

Given the choice of typing twice as fast or thinking twice as fast, I know I would choose the latter every time. That’s why I always choose to pair program when someone is available to. We accomplish far more together than we do separately. You’ll learn how and why when you watch Pair Programming.

In case you missed it, Steve Smith, Michelle Smith, and I are Kickstarting the 2016 Software Craftsmanship Calendar. Make sure to support and share the project so that this awesome calendar can make a comeback! We are dedicated to making this happen, but need your support.

This will be our fifth calendar, so we’ve got a lot of practice. None of us work together anymore, so we didn’t have a company backing the 2015 calendar. As a result, it didn’t happen. We’re going to fix that for all of the people who were contacting us and others related to the calendar trying to get their 2015 editions; the 2016 calendar is for all of you. I know it’s really early to be thinking about buying a new calendar, but there a printing deadlines, so we really do make these calendars in the summer. As a result of our efforts, those of you who were lucky enough to have the 2012 or 2014 editions of the Software Craftsmanship calendar got to have a picture of me up on your wall for an entire month for each of those two years! I have no idea if I’ll make it into the 2016 calendar, but it will see be awesome. Here are the pictures I was in!

Death March

Mushroom Management

In the spirit of explaining what goes into making each of these calendar images, I’ve decided to write a post here showing how the Mushroom Management photo got the way it is.

Step 1 – A Principle or Anti-Principle

We always start with some principle that we want to make. There are so many to choose from that we have to trim the list down to any we can get an idea for. That means that we start by brainstorming ideas, and keep the principles that we got any ideas for. It doesn’t matter how good the idea is. If we could come up with a visual we keep it and continue working on the visual. We have this set of criteria for the visuals:

The image has to relate to the principle.

The image has to be interesting enough to have on a wall for a month.

The image should have a humorous aspect to it.

Step 2 – Sketch the Idea to Make Sure It Works

Before we make any props, find a location, and start taking pictures, we have to make sure the idea will actually work. We also want to know what we need to set up. Not all ideas require this, but it helps choose between multiple ideas. It’s also a great point to iterate on before we start shooting. Often the sketches only resemble the image, which is why we spiked the idea with a sketch first.

Mushroom Management Sketches

Golden Hammer 2.0 Sketches

Frankencode Sketch

Step 3 – Make Any Required Props

The golden hammers we’ve used over the years were all made by us. We’ve made 4 different hammers over the years. Only two of them made it into calendar images. Two hammers were real hammers that we painted gold. One was a plastic hammer painted gold. The one featured in the 2014 calendar that looked like something Thor might wield was custom made by our designer Weston. He sculpted it, painted it, and even cut and wrapped the leather for the hilt.

The Original Hammer

The Thor Hammer

And this is how the hammer was made:

Step 4 – Start Photographing

Perhaps the most obvious part of the process, we do have to take some pictures. We make sure to take quite a few pictures (including some making of pictures to go in the back of the calendar). For the Mushroom Management photos, we did a photo shoot, and the photos were not quite right. We knew we needed to make some changes Take a look:

We really thought that the team needed to look like they’d been sitting in that room for weeks, so we did some thrift store shopping and obtained some visually “interesting” shirts for the team to wear. We also wanted to Mushroom Manager to look a little more formal. We shot again the next day. That got us here:

Step 5 – Touching Up Some Lines

And to make things look amazing, our designer takes these images and makes them complete. OK, so it’s a bit more than just a few lines, but the work he does is fantastic. We’ve gone from an empty office to a development dungeon.

Step 6 – Choosing Behind the Scenes Photos

Our developers in that pictures are in fact developers, not actors. They’re actually pretty uncomfortable in that room. They’re sitting on the floor, closed in a room, with the air conditioning off in the August heat. Being the mushroom manager, I’m supposed to be comfortable, so I’m making sure to stay cool. That’s why I made sure to wear the lightest pair of shorts I owned for this shot.

That’s how you really class-up an outfit right there. worn athletic shoes and blue shorts go really well with a sport coat, shirt, and tie. Trust me!

Step 7 – Enjoying the Calendar

Yes, this is our favorite part as well. When we get to see our first, fully printed calendar. It’s amazing to see thousands of hours of work come to life in the form of a calendar. Yes, we know the number of hours that go into these. NimblePros was in the software consulting business, so we tracked the hours we billed toward our internal projects like these.

I often feel like an arrogant jerk when I walk into nearly any business and my brain starts figuring out ways that things could be improved by applying basic agile/lean principles to some process or another. I think I feel this way, because I’m obviously not the only person thinking here, so there often could be a very good reason for things being the way they are. That doesn’t mean that I’m not going to implement these types of changes within an organization where I work though. Here at Clear Measure’s Ohio office, I did one such thing.

In previous organizations and other companies I know of, there is often a list somewhere of items that need to be purchased. It often looks something like this:

We often had questions about items that had never been purchased before. We often didn’t know who wrote the request, so there’s no easy way to ask for more input on the item. Additionally, if someone is running to the store, it’s easy to forget the items that are low, but aren’t on the list.

These issues and more are why I’ve moved this whole system into Trello.

What we love about this list is that we have a list of things we’ve ordered before, so that we can check that list for things we’re low on. It’s easy to make the request, and we can update this from our phones, computers, tablets, etc. It also lets you see who created a new card, so you can ask if there’s not enough detail to know what to order. It’s great for another reason for us as well. Many of our items are ordered online from the Austin office, so a physical piece of paper would be a challenge.

For you state or flag enthusiasts out there, that’s the Ohio flag in the background, so it’s really easy to tell that this is the list for the Hudson, Ohio office. Or as I imagine it’s commonly known by our Austin friends, Icicle Central.

It may not seem like it’s that big of a deal. I know a lot of people make sure to have a daily standup meeting either with just the team or involving the client. Either way, it’s very important to schedule these meetings in the morning. The reason for the level of importance I place on this is the tone of the meeting.

The most important thing to get out of a standup meeting is having everyone on the same page for what’s going to be done that day. You need to know who’s there, who’s working on what, if priorities are changing. It’s your opportunity to know what is going to happen that day (most likely happen).

If you conduct this meeting in the afternoon or near the end of the day, the tone can shift to discussing what did or didn’t get done. That’s all well and good to know, but it detracts from the discussion of the future. Remember, you only get so much time; use that time to make the next step a better one. Focus on where you’re going, not where you’ve been.

I am very grateful to be speaking at my 6th CodeMash. I’ve again been selected to present a precompiler on Software Craftsmanship (a topic I am very passionate about). I hope that everyone can attend my workshops. I’ve got two of them again, so I’ll be spending a full day working with software craftsman coding. We’ll be focusing as always on practicing, pairing, testing, and applying all of these effectively. We’ll work through ways you can use practice to learn new concepts and patterns to improve your skills at building great software.

Once again, Steve Smith and I will be presenting these Precompiler workshops together, so you’re sure to have a blast!

Our sessions are usually held back-to-back, so that you can attend the beginner session in the morning and follow it up with the intermediate session in the afternoon. Last year, our afternoon session had to have extra chairs and tables brought in for all of the extra people who showed up. My goal every year is to put on a workshop that will be the highpoint of your CodeMash! Join us for some great coding, learning, and practicing of your software skills.

If you’re in the Northeast Ohio area and want to learn more about software craftsmanship, you should check out HudsonSC. Our October meeting has been scheduled already. We meet on the third Wednesday of every month in Hudson, Ohio.

CodeMash 2.0.1.4 started as one of the coldest CodeMashes on record. On Monday, during the set up time for the event, the temperature in Sandusky dropped below negative ten degrees and the wind chill kept it feeling much colder. It was severely lacking in snow, but the cold was enough to cancel many of the Tuesday precompiler sessions whose speakers were not able to arrive at CodeMash on time to run the workshops.

The conference has grown to the point where it now has two initial days of workshops on Tuesday and Wednesday. Then the conference has two normal conference days filled with sessions. Considering that all of my favorite content is always the precompiler workshops on the first two days, I would love to see the conference have workshops through the entire event. I am usually one of the precompiler workshops speakers, so I might be a bit opinionated on that. From another viewpoint though, since I am one of the speakers during that time, I am often wishing I could attend workshops during the same time as mine! I love running the workshops though, so I gladly give up the other ones. I just need to figure out how to be in two plaes at once (future goal).

CodeMash Precompiler Workshop Details

For those who attended my and Steve’s Software Craftsmanship precompiler workshops on Wednesday, the weather was much more forgiving. Most people had arrived by that point, which meant that our attendance was also good. This was the fifth year that Steve and I had run this precompiler event at CodeMash. We adjust, change, and update the workshop every year. In the past, we had to teach a lot more about the basics of unit testing, but now more people have at least some knowledge of unit testing.

Over the years of doing this workshop here (and similar ones elsewhere), we've found a lot of good techniques and exercises for working with the attendees of the event. We try and experiement with lots of exercises and katas at conferences, events, and user groups, because we're looking for great ways to teach these types of events. When we run them, we are always trying to make sure that most of the event is spent coding. Through this, our goal is not to give an exercise to the attendees. Our goal is to teach them how they can continue their exercising and learning after they leave the event. That's our goal.

We use a few types of exercises: gateway exercises designed to teach you how to practice, guided exercises leading you down a path slowly with steps for freedom along the way, and open-ended exercises giving great freedom and possibilities in final implementations. As part of the open-ended exercise, we often attempt to use that as a plane up which to build a specific type of implementation. We will choose a principle or a pattern and use this plane as an area in which to practice following the principle or pattern. This shows the students how they can leverage programming exercises as places to learn new principles and patterns.

Beginning Software Craftsmanship Workshop

In the morning, we start out our session for beginners just learning software craftmanship. This course is for people familiar with programming (using any language) that want to learn more about software craftsmanship and work on programming exercises with their peers.

As we do every year, I started off the discussion by explaining software craftsmanship and giving an introduction to its concepts. I explain the software craftsmanship manifesto, what it means to developers, and how it relates to the agile manifest. Through this talk, I always make sure to emphasize the importance and reasons for deliberately practicing. As the entire audience will agree, when under a deadline they jump back to their poor practices they know aren't the best. Practice is how we drill ourselves to handle the situation in our own desired way. I make sure that the audience knows as well as discussing and working with others. If I can encourage more people to attend and start software craftsmanship groups, I would consider this talk a great success.

Once we had the reason for why we're all here, we start getting into some of the meat of the workshop. Steve then presented his well-honed talk on software principles. Most of them are designed for object oriented programming, but many are applicable to nearly any language or paradigm. Along the way he of course will cover SOLID, and the slides all contain images from our Software Craftsmanship Calendar. The 2014 edition of the Telerik Software Craftsmanship calendar is out, and everyone at CodeMash received a copy of the calendar.

While Steve is wrapping up the end of his presentation, I start passing around sheets of paper (yes, real paper) containing a printing of the first exercise we'll be doing. For our first exercise, we were doing FizzBuzz an exercise that is simple enough that it gets people used to the idea of practicing. This is our gateway exercise. We use this to make sure that everyone is set up with their tools. As long as their setup allows them to write code and run tests, it should be good enough. We include some extra credit with these, so that most people can at least get close to finishing the first part of our exercises. Some people will finish the extra credit, which means that we can have nearly everyone reach a stage of accomplishment.

We also ask that the entire group pair up, so that they can work on the exercise with others. This accomplishes quite a few things, including helping those who don't have a computer with them.

Interrupting everyone's coding is always a challenge, but I make sure to do it nicely. A microphone helps with this! Now that everyone is set up, we take a break from the coding to talk about practices that we promote to the group. The first of these practices is testing. As is still the case, most people are testing or at least familiar with the practice. As a result, I cover this topic briefly making sure to emphasize the different types and their importance. There are still many groups forced to write integration tests instead of unit tests for example. We discuss how to avoid that situation in the afternoon when we discuss more good practices.

The second practice that we discuss is continuous integration, however, since we don't have the time to set these up on everyone's computer, we only discuss this briefly and suggest that people try them.

The third practice is pairing, a practice that we've already had the group start in their first exercise. Not only do I cover the methods of pairing, but I point out all of the good pairing practices that everyone was using without thinking. I then point out the importance of changing partners and typists frequently. In their first programming exercise, very few people change who is typing. Since pairing is such a hard activity, we also make sure to cover all of the things that you can do to improve your pairing by changing the environment in which you're working.

The String Calculator is a guided exercise in which you only read one step at a time. Each step has parts to it, but you do them one at a time. This follows the normal scenario of receiving your requirements a piece at a time. It also keeps you following a plan and gives you a great chance to follow YAGNI. The students do well with this, and it's an exercise that does very well on paper, since you can fold the sheet over the future steps.

Intermediate Software Craftsmanship Agenda Workshop

After lunch, we started our second workshop. This one is a half-day workshop designed for people who attend the morning workshop or are already somewhat familiar with software craftsmanship, deliberate practice, or who just couldn't fit the morning session into their schedule.

Steve starts off the talking in the afternoon discussing design patterns. Steve is an expert in design patterns and refactoring, so he's a great person to present this workshop with. Steve covers a lot of design patterns in this talk. You'll notice that a lot of these patterns have overlap and many of them stem directly from one or more of the principles mentioned in Steve's morning talk. This is not a session to miss!

Once we're done with the design pattersn talk, we make sure that we start everyone on an open-ended exercise. This year's was the greed dice game scoring exercise where you create code that will score the results of one roll in the greed dice game. It's a simple exercise, but can get a bit unwieldy if you're not refactoring or implementing a good design. We don't suggest that anyone try any specific design for their first attempt.

We follow up this programming with even more programming practices to follow. I do this talk, which is about more advanced types of testing using mocks, fakes, stubs, etc. We want to make sure everyone knows how to do these. We sometimes do an exercise that can leverage these skills, but we did not this year. We instead showed a quick demo of doing this with a logging system that logs to the file system.

Back to Greed again for the final exercise of the day. We finish out the workshop asking everyone to program the Greed game scorer again. This gives the students the chance to attempt a more complex solution to the problem this time around. We had everyone attempt to implement a Rules Engine for the second attempt, which will allow them to follow the Open/Closed Principle.

Overall we received a lot of wonderful feedback from our students, and I hope that everyone who attended goes on to continue doing what we taught in that workshop. Thank you all for attending. Thanks CodeMash for putting on a wonderful event and inviting me and Steve to run one of your precompiler workshops. It is always a fantastic time! I look forward to seeing more of you there in the future. Have a great 2014!

I enjoy the Agile Ball Flow Game. It’s a challenge that emphasizes a lot of what agile practitioners find value. The theme of the game is that you’re working in a toy factory and you create toys by passing them around to the other workers. Each worker needs to touch the toy at least once, no two workers can touch the same toy at the same time, and you can’t pass the toy to the person next to you. As orders come in, you try to complete the orders as quickly as possible. If you mess up one of the toys (drop it), you have to start over creating the toy.

In the game, you want to keep track of when you start making each toy and when each one completes. This lets you track your lead time, cycle time, WIP, etc. From this information, the group can see what works well and what doesn’t. They can determine how to adjust their process to improve their toy-making abilities.

At the Hudson Software Craftsmanship meeting earlier this week, we performed the agile ball flow game. No one there had done it before, so it was a great opportunity to see how they would organize themselves and complete the solution. In total, we had 14 people at the start of the game.

Round 1

I started the group off with 20 multicolored balls. The hollow plastic variety commonly found in children’s ball pits. They’re easy to toss short distances, but can be tricky for a long distance toss.

They first created a circle to facilitate passing. One thing they did very right was passing 1 ball around as a demonstration so that the whole team could practice and get an idea of what they were going to be doing. Much better than just assuming that everything will work as expected!

They completed the full order of 20 in just over a minute and thirty seconds. A few of the balls dropped, but were picked up and reintegrated into the process. Their effective process worked so well, because most of the team had enough slack to not feel overwhelmed.

Round 2

In the second round, the team estimated that they would be able to complete things faster. They estimated the time to complete to be around 45 to 60 seconds.

As part of their retrospective, they realized that their pull model they were using worked effectively, but if they shifted forward and backward a little bit, they could pass more easily. This was their slight adjustment to the process.

It worked! They managed to keep more balls from falling in the second round and really improved their time! They noticed that their issue was in contentious passes around the circle, and they adjusted to account for it. Well done! They were a hair under 40 seconds, which is the fastest second round time I’ve ever seen.

Round 3

Kids these days aren’t just interested in those old-style toys, which means that the challenge needs to change a bit. They’re still fun, but the new thing is dart guns, so now the team needed to also pass around foam darts. With such a well oiled machine, could these darts present a challenge?

The darts are tricky, because one end is rubber and weighs a bit more than the other end. These were obviously more challenging to pass, and the group spent some time discussing how they would work.

The team decided to start with the darts to get the more difficult items out of the way first. At first, this seemed to work, but darts started falling. After starting most of the darts a second time, the group ended up with a time just over a minute and twenty seconds. Not bad, but quite a fall from round 2.

From the retrospective discussion, the group established that they needed to drop the darts into people’s hands. Tossing just wasn’t working well. They also decided that they should probably send multiple darts at a time since they were going to be dropping them, it should be safe to do.

Round 4

Armed with a new plan, the group decided to start the darts 5 at a time, which would mean 2 sets of darts traveling around the group.

Not surprisingly, only 3 darts of each set made the round trip. Still probably an improvement, but it might have been better to have done 2, 3, or 4 darts at a time instead. Perhaps something to try in the future.

This round was full of dropped items and ended with 1 dart making the rounds all alone. In the end WIP was just 1 for the whole group. The time wasn’t bad, but it was obvious that the group could do better. So far they hadn’t made any huge gaffs either though.

Round 5

This round was about being more careful and getting the passing in place as best they can. Perfect answer, team. They knew not to make big changes. What they were doing was working, and they were seeing improvement. A big change here would just upset things.

The group finished on a high note, being one of the more successful groups at ball flow that I’ve seen. They completed the challenge like champs. Not once did they try something crazy like shooting WIP through the roof (I’ve seen it!)

Agile tells us that we need to limit WIP and bring cycle times down. Those are the focuses of the agile ball flow game. It lets the group self organize through planning, spiking, testing, and doing retrospectives. If you want to teach a team about agile, the ball flow game is a great way to do it!

I primarily use Karl Scotland’s method of running the agile ball flow game. Make sure that you also use this spreadsheet template when running the game. It makes tracking times much easier.

One of the agile communities mocking terms of the old-fashioned Waterfall development technique is, “Waterfail”. It is called this, because the community credits this technique with being part of why a lot of projects fail.

The main difference between this technique and most agile techniques, is that waterfall does one big flow of everything. It does not loop through the process as most agile techniques do. It attempts to have everything planned out so that you’re just going through the motions toward success.

I’ve been posting each of the topics from the NimblePros software craftsmanship calendar as we get to the month. With each of these, I am mentioning that you should work on trying to follow the good practice or avoid the anti-pattern. Since this year’s calendar is on anti-patterns, it included Waterfail as something to avoid.

So for the month of August, I am going to recommend trying to move away from Waterfall. I’m not saying that you should suddenly move from a Waterfall project to some form of an Agile project. At least start looking into the possibility. Read a book on agile, go to an agile or software craftsmanship user group, access online resources for learning agile techniques, or attend a conference with an agile track.

I really liked how well this image turned out, and if you didn’t notice, we wrote “Waterfall”, but we cut part of the first “L” to make it appear to say “Waterfail”. Just one of our subtle little tricks in the calendar.

Programmers are talented, smart, skilled professionals. We put in lots of our own effort to educate ourselves and stay up on current technologies. We work hard and we feel great satisfaction in our achievements. We donate our time to charities when the opportunity arises. We give back to our local communities. All things considered, there are a lot of really great programmers in the world.

I lead a team of software developers. Does that mean I am the “best” programmer on the team? Certainly not. It just means that I lead the team. As the leader of the team, it is my job to: inspire, encourage, trail blaze, and motivate my team to be the best they can be. So who is the best programmer on my team? I don’t know, and I don’t care. There shouldn’t really be a “best” programmer on the team. Everyone on the team is great and working hard.

A team that really meshes and works well together doesn’t let egos get in the way. It doesn’t matter if you’re a rock star developer. When you’re on the team, you’re part of the team. You might be the JavaScript expert, the master of SQL queries, or the guy who can refactor anything. When you’re part of the team, you should try to use your strength, but don’t let that interfere with the team’s flow.

Sometimes it makes sense for a more experience developer to work with a less experienced developer. A common first instinct is that the senior person is mentoring the junior person, but it’s actually going both ways.

Each of the two developers is bringing a lot to the table. Their different experiences and views allow them to each approach the problems differently, ask different questions, and apply different, existing knowledge.

If either person’s ego gets in the way, it would prevent the 2-way knowledge transfer in addition to creating friction between them.

One Developer and one Junior Developer can pair on a task and share knowledge. Does one act like the other one is just along for the ride? No.

Your pair partner, is watching your back, guiding the team, and keeping the pair honest. Which one does that job? Both. If you had one person drive the whole time, you’re not going to see the benefits of pair programming.

If you let your ego get in the way, you might not let the junior developer write any of the code. They may not know every library, every design pattern, or even the intricacies of the language they’re using, but those guys can write some great code.

I don’t know how the Junior Developers are on your team, but ours write great code and show a high level of professionalism in their work.

And sometimes you get a Junior Developer pairing with the Developer Intern. How the pairs split up doesn’t really matter. Who is working with whom doesn’t really matter. Each and every member of the team is bringing something to the table, and it is this interaction that is making the team as effective as it is. These two are as productive a team as any other pairing that we’ve got.

Someone is probably reading this and thinking I am crazy for letting a Junior Developer and a Developer Intern pair together. They’re good though, and they really get great stuff done.

We can accomplish a lot of stuff when our team works individually, however, we can accomplish a lot more as a group. You might be the “best developer” on your team, but if you keep thinking and acting that way, you’ll be missing out on a lot. I learn a lot when I pair with any member of my team. It doesn’t matter how much experience the person has. Everyone knows something I don’t, and no one approaches the problems exactly the same way I would.

There is no “Ego” in “Agile Team”, so don’t bring yours to an agile team and expect good results.

The book goes through many, many examples from the author’s development experiences. It has sample discussions between parties to explain points and really goes over professionalism in software development.

The Title

The impression I have about why the book is called “The Clean Coder” is mostly a play on professional developers wanting to have clean code. This doesn’t just mean the code, the code is included of course, but it also means that the whole coding experience and the whole project should be clean.

There are a lot of mistakes that developers can make, and the book is covering them and discussing how to keep things clean.

The Material

Without jumping into too much of the meat of the book, I will say that there are many things in the book that I’ve done before and don’t do anymore. There were some things mentioned that I’ve done recently, and I am going to make sure I never do again. There are some things in there that I’ve thankfully never done, and I hope I don’t ever do them.

The book focuses on a lot of bad situations, why these situations are bad, and how we should really be handling things.

Consider this book to be a guidebook of suggestions for how to act as a professional. For example, in the book’s discussion of estimation, instead of focusing on how to be more accurate with estimation, it covers how you should be estimating. This means that it tells you that you should be very clear about things being estimates, not to imply a commitment, and not to make commitments if you cannot meet them.

Controversial Points

The Clean Coder makes some recommendations that I am sure that plenty of people will disagree with, and the way some points are worded cause me to sometimes disagree as well, but I don’t think it really takes away from the value of the book.

One example of this type of suggestion is that you work 40 hours a week and then another 20 each week on improving your career, leaving 56 hours for sleeping and 52 hours for everything else. It’s presented as doing this makes you a professional and not doing it is not professional. What I disagree with is the definite amount of time. I think it’s important for people to work on their careers, but 20 hours is arbitrary here. Someone may get the same value out of 10 hours that requires me 30 hours. There also is no definitive line between professionalism and unprofessionalism. There are some gray areas, and I believe this would be one of them.

Some things in the book were kept clear that it’s how he works, and I took these as suggestions to learn how I work and make sure that I am evaluating a possible issue.

In this case, I am referring to a point on music. Some people listen to music lightly while programming. This is even true when pair programming. I sometimes like having a very light bit of background buzz from music while pairing. In this case, I keep it so quiet that we can still communicate easily. The book seems to be against music, since it distracts and changes the author’s thinking. For me, I think I don’t have this issue because my pairing partner prevents a change in thinking. I also try to listen to music with foreign lyrics or no lyrics at all. It also helps to not distract from the task at hand. The value here for me is that I should be evaluating and thinking about how I am doing things to make sure that something as seemingly inconsequential as music is not detracting from my work.

Meetings

One great suggestion made by Uncle Bob is that it’s OK to decline a meeting invite. I think that’s very important to understand. Unless you’re really needed in the meeting, you should try not to attend. Meetings take up time, and if it’s less important than your other work, you shouldn’t be attending.

I had a meeting I scheduled yesterday. I invited 8 people to that meeting. I made sure it was clear that if you had something to bring up, you should attend the meeting, otherwise your attendance was not required. We had 4 people in the meeting, and I think 1 of the attendees need not have been there anyway.

Trying

You should read the section on trying. It’s important not to try, and this book makes it very clear why. If you’re going to try, you’re making a commitment to try.

Mentoring

The first paragraph on the chapter on mentoring illustrates one of the biggest shortfalls of the software development industry. I owe a lot of my successes as a developer to the mentoring that I’ve received through books, blogs, and any other recorded sources of information I can get my hands on. I was also lucky enough to have a mentor and a role model to learn from as I became a better developer.

Summary

If you go in to this book expecting it to be a recipe for success, you will be mistaken. This book is fantastic, but it’s important to think and consider why it’s valuable. It is one developer’s experience as a developer.

From his own stories, he is a developer who has hit some pretty rough patches and made some terrible mistakes. That’s a good thing! It means that he has learned a lot!

While reading the book, I never felt like it was forcing his way of doing things onto me. It is presented in a great way to inspire changes in the developers who read the book. You don’t have to do the same things that he is doing, but try to consider what the right answer should be.

The examples are simplified for the book, and business are more complex than what is in the examples. The reader will need to adjust and make decisions, but that’s what you should be doing anyway. Think about being professional and doing what you should be doing.

This book has been on my intended reading list for a while, and now I am going to recommend it to other people.

Well done, Uncle Bob. Thank you for sharing your experience with everyone.