The Craftsmen Aren't Crazy

My fellow apprentice Stephen had a great blogpost that I really just want to ditto. Stephen hit the nail on the head and I want to add some ideas his main points:

1) "I write tests because I want to code well and fast": I think it's important to note the huge amounts of time we lost because of poor code coverage. Weeks of work went down the drain on slippery bugs nested in tightly coupled code. The code base was begging to be refactored, but we simply couldn't without first testing the nasty code that wasn't our own. Furthermore, it was enough work to meet our stories on time in the system so refactoring outside the scope of our stories was rare and I wish it did not have to be that way. Test coverage is amazing. It drives simple development and loose coupling.

2) "Team communication is key": No matter what the circumstances, be communicative. I learned that it's more important to ask trivial questions than worry about looking dumb. We are not impressing the other developers on the project, we are impressing the client.

3) "Communicate religiously with the client": Acceptance criteria is almost always not specific enough. Do not let the client get away with specifying vague stories. This will always come around to bite the developer when the developer's vision does not match the client's vision. Also, use acceptance criteria to force the client to understand what it is they want implemented, exactly. Colin and Justin gave some insight into their troubles with the client not understanding the story they were asking for and it really changes the flow of the iteration as time moves forward.

4) "Pair programming is awesome": It is awesome! Our project implemented code reviews and the process was more tedious and less productive than pair programming in all instances.

5) "Clean code matters": As the project grows in size dirty code gets dirtier and dirtier. It receives 'bit rot' and even though it's been working as is the entire time it can sneak in and break the project. It collects dust. A feature you thought lived totally on its own is now breaking all of the tests. It's terrible too, since it's completely avoidable. Coming off of this project I understand the importance of clean code in the scope of a big project (especially one that is only getting bigger).

The Professional Side of Development

This week was my first week with the Bridge team and it has been a learning experience. I came into my apprenticeship looking for experience in the workplace. During my time at school and while coding on my own time I'm usually working by myself or in very small groups. Our projects are usually limited in scope and intended to teach about a specific piece of the discipline. If a school project is rushed and contains untested sloppy code, that's usually okay as long as it runs. After submitting code for class I usually never look at it again. This project is different.

I joined the project, I did not start on the project. This is the first learning point. Coming into an established codebase can leave you feeling lost. It's like moving to a new city and not knowing where anything is, how to get anywhere, or how the transportation system works. The approach I've had so far is to keep in mind the scope of my problem and avoid heading into areas that I do not need to be in. That way I can focus on implementing a feature without being concerned with other areas.

The second learning point is the multitude of languages and areas of concern when building a web app. I started my apprenticeship not know any javascript, for instance, and I've been learning as I go. It's exciting to take on new languages and be able to control different areas of design than what I am accustomed to.

The third learning point has been everything involved in a project that is not code. Each iteration takes a lot of planning. Communication is constant (daily standups, weekly iteration reports, plus any extra communication needed) and requires a skill set that is very different than the skill set to sit down and write code. I'm learning about workflow and processes in a professional setting, which is a skill that I think one could only learn by doing.

8th Light is getting to me. The project didn't have acceptance testing and I am actually excited to add acceptance tests. Who would have thought?