The Code Dump

Continuing on this series of the Autonomous Craftsmanship Core we now reach the methodology problem.

“I want to do agile/craftsmanship/etc.”

The key is basically to put the rest of your team aside and focus on how you can do things like you think they should be done. You want to do “agile”? Open the manifesto, read the values, and think on how you can change your own process in order to further yourself the direction you want to get.

Development Practices

This one deserves a post of its own, but luckily for us I’ve already written it! You don’t need permission to write tests, use the right tools, and just coding in an awesome manner.

Your own mini iterations, planning and retrospectives

I think a big part of becoming a better developer is looking at how we work, analyze it, decide where we need practicing and then getting better at it, deliberately. Here are some examples from my own development process.

Pomodoros

I love pair programming. Love it. Love it so much, I find it hard to be productive without a pair when coding. I find that the crazy simple Pomodoro technique is some kind of magic makes-me-focus-real-good drug. Anytime I’m doing tasks on my own I set up my little timer and burn down the todo list. Using pomodoros allows me to keep track of my time, focus, see how good are my estimations and waste less time on reddit. You don’t need anyone else on your team to “allow” you to do pomodoros. Just do it, and see magic happening.

Goals and Retrospectives

Just like in an agile team we plan sprints, have retrospectives and set goals, I do the same for myself, both at work and for my personal time. Every week I do a retrospective of the past week, think what I did wrong and what I like. I have monthly and weekly goals. I’ve got recurring tasks in OmniFocus to review my work. I write the reviews in Evernote and then create new goals and add them to OmniFocus. That way every week and month I can go over the last few weeks and see how I’m doing. For example, I can set goals for finishing a book, write some blog posts, communicate better at work, etc.

It’s up to you

Uncle Bob Martin said it’s not your boss’s responsibility to make sure you learn and become better, it’s yours. Once you realize this, stop waiting for things to get better by themselves and step up you can actively become better. I was surprised how many of these aspects coincide with what Seth Godin talks about in Linchpin. You have no excuses not to be doing better things. It’s you’re responsibility, so stop bitching and do awesome work.

You should subscribe to my feed or follow me on twitter!

Pushing forward with the Autonomous Craftsmanship Core series. This week on our plate: How can you force pairing down the throat of your team even if they’re not really into it?

I’ve already touched on this subject a few times before, especially since it’s one I find really important and had to handle a few times before.
Pair programming feels to me like the best technique currently known to the software industry for making a team highly productive and have global code ownership. It’s one of those things that didn’t click right away when reading Extreme Programming Explained, but man did I get it wrong.

I’ve loved pairing from the moment I started doing it and ever since I find it hard doing hard work without a pair by my side. The problem is that most of the software shops around are still not pairing regularly, making it hard for a pairing junky like me to have fun.

So, how can we stop bitching about our team not pairing and actually get shit done with a pair? As opposed to the previous posts on the Autonomous Craftsmanship Core, this is not something one can do alone, and so is a bit harder to work around.

Basically, don’t calling it pair programming. It might be a bit tricky socially, but it’s worth it. Some real examples:

Can you help me out?

If I have a short task (ideally – no more than 30-45 minutes) that I want some help with, I just find someone on my team and ask for some help. Hopefully, you’re not in a team where asking for help sounds problematic. Then, once you’re both on your computer and working on the problem – you’re pairing. That was easy, wasn’t it? Do it enough times (without looking like an idiot that always needs help) and your mates get acquainted to the idea fast.

Volunteer to help people

I love walking around the team and seeing what people are doing. Every once in a while, simply walking by someone and asking how are things going might trigger a “Take a look at this” response, and you can help a fellow coder get unstuck. I used to do this even outside of my team. Spending 15 minutes with someone to help him solve a problem and share some knowledge and technique in the meantime is just awesome.

Review code to be in the loop

I try and read most of the commits being done to projects I’m involved with. It has many advantages, and one of them is that I’m familiar with most of what’s going on around me. That means I might find little problems, ideas and changes that might help my team. I then just go to the person that made the changes and share my ideas. Sometimes that would drag us both into a short pairing session.

These are basic techniques that I’ve found helpful several times. Even people that have never heard about pairing start liking it (if they really find you helpful and not annoying, of course). I just love seeing how after a few weeks, people come and ask for help if you’re not around, and how slowly the idea of doing some tasks together becomes obvious. I don’t have to have them call it pairing, and it doesn’t have to be 100% of the time. The bottom line is that good practices stick, even unconsciously.

You should subscribe to my feed or follow me on twitter!

Continuing on the thread of the Autonomous Craftsmanship Core, we reach another problem: “they” just won’t let you use the right tool, or in the right way. As I’ve said in the previous posts if anything is so bad you can’t work with it – leave; otherwise, you gotta learn how to make do.

A pragmatic programmer uses the right tool for the job. We all know that if you have a hammer, every problem looks like a nail. In this post I’m talking about the situation where you have an awesome toolbox right there and yet they’re forcing you to unscrew something with your pinky’s nail. Excruciating to your brain.

The thing is, a lot of the times you can just use the right tools and the hell with everyone else. Yes, you can’t just write code in whatever programming language you want, but in a lot of other situations, you can do what you want to. I think this is best shown with a few examples:

“Don’t commit too much. Say once a day”

That’s a real quote a friend’s boss told him. Turns out committing multiple times a day is too messy. Most programmers might just sulk and do as they’re told, but with today’s technology you’re no longer bound to these stupid rules. Your team uses subversion? So what! You can use Git locally, do whatever you like, and just push once a day everything via git-svn. Same solutions are available for just about any VCS combination you can think of! I’ve done this several times working on projects with a VCS I didn’t want to mess with.

“We can’t have a CI server”

Why would someone be against that? Maybe your company doesn’t want to allocate a new server for such a “useless” thing, or maybe the system admins don’t have time for your little “developer toys.” Lucky for everyone, it’s no longer the case that you need complex setup for such stuff. It’s just a matter of looking around. For example, if you’re doing open source you just need to give Travis a look and see you’re suddenly all set. On the other hand if you’re code isn’t open sourced setting up a local Jenkins server is so so easy. You just double click a file and you’ve got it running. If your build isn’t too CPU hogging, you can run it on your box! And I’m almost certain you can find some server with some spare cycles to install it on.

Autonomous Craftsmen Make Do

That sums it up. A craftsman’s gotta do what a craftsman’s gotta do.

You should subscribe to my feed and follow me on twitter!

Diving deeper into the idea of the Autonomous Craftsmanship Core, this time I’d like to talk about one of the first problems a lot of developers face when wanting to start doing clean code.

You read Uncle Bob’s Clean Code, or went to a talk and then go all “Next day at work I’m gonna write tests!!” Then you come to work, and you give the “let’s write tests man!” speech to your teammate, and he just yawns, and slowly the rush fades.

Lots have been written before about introducing tests to a team as a grunt, but I’ll do a quick recap:

You don’t have to ask anyone in order to start and write some tests. Write that first test. Make it pass. Commit. Not that hard, isn’t it?

Usually the next problem is that if no one else on your team runs the tests, they will keep breaking. But can you blame your team? You need to make them understand that running the tests will actually get them something.

For example, I’ve seen that after someone makes a commit that breaks the tests because of a bug, coming over to him and telling him what went wrong and how you found out might make him more interested in the idea of testing. A friend recently told me that he made running tests as simple as a double-click for the developers that don’t write tests. Once it got that easy, they started running them because everyone likes knowing that what they wrote works.

What if your boss won’t let you write tests? Frankly, why the fuck should your boss care? Does he also tell you when to use “while” instead of “for”? I don’t find things such as these to be something any boss should decide about. As I’ve said in the first post, if you find yourself in a place so resistant to change, leave. If you have to stay, do what you have to do. If they won’t let you commit your tests to source control or set up a continuous integration machine, there are solutions, which I’ll discuss on my next post.

In the mean time, focus on writing tests that help your teammates find problems and see how slowly your little tests get more and more traction. It’ll work, because Success begets attention!

You should subscribe to my feed and follow me on twitter!

A lot of developers I know keep bitching about how their team isn’t as passionate as they’d like it to be, or about their boss not letting them do things like it should be done. They get into this habit and never advance in the right direction because something is holding them back. I know this situation well, I’m usually one of these guys.

In the spirit of Positivember I’d like to tell you a secret. You can stop whining and start improving. You don’t have to wait for all the stars to align. That cliché about changes starting from yourself is actually right.

I’ve heard almost every complaint in the book:

“My teammates don’t write tests.”
“They won’t let me have a continuous integration server.”
“I can’t use Git.”
“My boss hates it when I make a lot of commits.”
“I was told not to write tests.”
“We’re not doing agile development.”
“I can’t do pair programming.”

If everything above applies, or you really have lots of problems like these, just quit. A developer that really cares about these things usually can find a better job easily. But, if it’s only some of these, remember that no work is perfect. There will always be suboptimal stuff to live with. The trick is not to be all bitter about it, but to actually try and make changes happen, slowly, so you still have fun.

Most if not all of these problems are things you can work around, technologically, mentally or socially. If you just stick to your good ways, you’ll eventually get some followers too.

Step up and realize that everything can start by you and your habits. An Autonomous Craftsmanship Core as I like to call it. Sometimes, you core will seem so awesome from the outside that people will join in on some of your practices. Sometimes it will go unnoticed and you will happily go on programming better and better.

I will blog more on tackling some of the problems I mentioned above, but as a starting point I recommend Apprenticeship Patterns and Driving Technical Change. These great books help a lot in accepting that fact you should take matters into your own hands, and stop bitching.

You should subscribe to my feed and follow me on twitter!