This week I attended the 33rd Degree conference in Kraków. Most of the time I followed the “soft” path and learned how people work and how I can improve my skills (not only as a programmer, as it turned out). Here’s a quick summary of some of the valuable stuff I got there. It’s going to be fairly shallow, but anyway there is no way I could describe 25 hours of talks from very smart guys in a single blog post.

Tunnel Vision

Like all people, developers tend to get tunnel vision. When you’re in the flow, you don’t care about the big picture. You just crank out code and your thoughts are faster than your fingers. The more you focus on detail, the more you’re biased and suffer from inattentional blindness. Vision, scope and quality fade to background. That’s not good, because you’re a part of a bigger machine whose basic purpose is delivering business value.

Paweł Lipiński did a great job explaining how various agile tools address it. User stories clearly state what business value you’re about to deliver. Programming in pairs prevents individuals from getting out of control by having one programmer paying more attention to the strategic vision. Finally, several layers of tests (including acceptance tests) verify that the specification is met even as the code is refactored or extended.

Marcin Kokott and Martin Chmelar tackled it from a broader perspective. Sometimes companies realize something is wrong. They’re not going fast enough, or what they deliver does not exactly meet business expectations. So they hire consultants like these guys who talk to all involved parties (from developers to executives) and investigate how the whole process works. What happens from the moment a feature is described to when it actually is implemented. Sometimes the problem is not in developers, but on a higher level of the whole process. For instance, marketing or stakeholders generate so much pressure on developers that they produce poor code and don’t meet expectations. That leads to more pressure and demotivation of developers… and so we get a negative reinforcement loop that leads to inevitable failure.

Another topic that the two Martins touched is how experience adds walls around you. You get used to some way of thinking and get less and less creative. You no longer try and think outside of the box. You become prejudiced and make pessimistic assumptions. In his final “Abstraction Distractions” key note Neal Ford followed it by stating that what shields you from the world at some point can become a prison later. We think of file systems, while our users only care about documents. They want to move pictures from the camera into the app – not think about folders, JPGs, mounting an external storage or whatever (example from my experience). We are used to so many abstractions. It’s interesting how it took 30 years to market user interface that has no file system, no mouse and keyboard (that is the iPad). It took quite a while to make the breakthrough.

Finally, Matt McCullough made an interesting point. In both his talks on Git and Hadoop he stressed how you should always try and understand your tools on one level below what you need right now. It not only helps you understand the thing better, but there may be some very interesting and worthwhile piece of engineering underneath you can learn from. Oh, and in just one hour Matt managed to explain how Git works and make me actually want to give it a shot. Something that many other advocates could not make me do.

Sharpening the Axe

Another recurring topic was self-improvement. First of all, why should we care? Why not just hold on to your knowledge of the good old Java as of 2005? Quick answer: To keep your job. Longer answer: Because that’s professional. Constant self-improvement is part of the job. If you don’t do it, you will be unable meet new requirements. Web development? Fancy Ajaxy UIs? Scalability? Big Data? Standard requirements today, hard if not impossible to solve with the technology and knowledge as of 5 or 10 years ago. In fact, you even may want to learn out of boredom! But how?

There is no way to describe what Venkart Subramaniam and Ted Neward have done. Not only they had a lot of great thought-provoking content to present, but they are fantastic speakers (true rock stars in the old good rock’n’roll sense). Their frantic enthusiasm and passion were truly contagious. Venkart compared learning to mental exercise that you do to stay energized and in shape. To get the most out of it, you should learn something completely different from what you know. No point learning C# when you’re a Java master. Go learn Clojure or Erlang – something that hurts when you first do it! Even if you don’t use it directly, it may change the way you think in your primary environment (that’s what I loved in learning Clojure). Another nice side effect is that the more you know, the less effort it takes to learn another new thing (because you just learn the deltas).

On the other hand, Ted stressed the fact that there’s always a wide range of tools to choose from. There’s no silver bullet to be found. Some tools work here, some over there. You may or may not need JEE. Or Rails. Or Hibernate. Or blub. You can’t blindly apply whatever your current favorite toy is. Be critical. Even worse, you can’t rely on authorities or community to tell what’s the best. There’s no such thing as universal “best practices”. Everything depends on context.

Productivity

Finally, I really enjoyed two talks on productivity by Nate Schutta and Neal Ford.

It all started with Grzegorz Duda urging participants not to tweet about the conference (his conference!), but focus on the real people and stuff around them. Not too long after that Nate gave a great talk about the broader context of productivity. First of all, to be productive you have to be physically healthy. If you sacrifice sleep or physical exercise, your productivity actually goes down due to fatigue, poor blood flow etc. Another side of the same coin: Time and attention are limited. You only have so much time. There’s no way you can experience, enjoy and learn everything. You have to be very picky about everything you do. Are Twitter, Angry Birds or TV really worth it? Go on an information diet and be selective about everything you pick up. Drive towards doing fewer carefully chosen things in much more depth.

Compared to this, Neal’s talk was very down to earth. He shared many tricks that can make you a more productive programmer on a daily basis. Go faster by using keyboard and shortcuts of all kinds for everything, because typing is a lot faster than navigation. Mouse is for your grandmother. Stop repeating yourself and automate everything. Stay focused by getting a more comfortable environment – comfortable chair, dual monitors, virtual desktops, full screen applications, and so on. Avoid duplication by having one canonical representation of everything. If you need to update docs to keep rest of the team up to date, maybe you can generate an RSS feed for them from the VCS commit log? Finally, automate everything. Use one-step build, continuous integration and automatic tests. Don’t force yourself to interact with what you’re building – use a test suite such as Selenium to do it for you, and run it repeatedly as often as you need. Make your QA record their steps in Selenium so that you can easily and accurately replay it.

Be a craftsman, not a laborer. Build your own tools if you need.

Driving Change

One recurring question common for many different topics was: That’s all cool stuff, but how do you drive the change? How can you do it in your company? How to change yourself? The same question applies to developers’ observations on problems in the whole process (supposedly beyond their responsibility), but also to introducing new technical solutions (languages, techniques, libraries) in development itself. Even to self-improvement outside software development.

If you’re lucky, you may be in a team like the one Jakub Nabrdalik described. A bunch of people who want to improve their skills and company themselves and have enough determination to convince the boss to do it in their paid work hours. For example, it could be weekly workshops, presentations or team code review. More on that here

That’s great if you’re in a professional and energized team with an understanding boss. If you aren’t that lucky, you may still be able to sneak some stuff in. Clojure community has heard of the anecdotal way to introduce their favorite toy: Don’t call it a language. Java is a language. That’s a Huge Deal. Don’t do it, just call it a concurrency library for Java. Another example (thanks Artur): Use Gradle to solve a tricky build problem that would take 1000 lines of Ant… and open a back door for Groovy.

Venkart Subramaniam used a great metaphor. Imagine an elephant rider. Of course when the elephant takes control, it will ride wherever it wants. It won’t go somewhere only because the rider frantically says so. But if the rider is smart and rational, he may be able to control the elephant. That elephant can be your environment, or your inner lazy, prejudiced and emotional self.

Last but not the least, be a child. Drop your assumptions and prejudice. Just try it – it may simply work!

Next Year

This lengthy post may not even cover a half what I was able to see at the conference. It merely scratches the surface and does not give even a slightest hint at the great atmosphere there. Grzegorz Duda made an excellent job in organizing the event and gathering so many talented speakers. I already am looking forward to the next year. If this was only the first edition, the next one can be an earthquake. The preparations have already begun and with such stars as Uncle Bob on board it just can’t go wrong.