Lessons Learned in 2016

I started 2016 with the goal of solidifying my technical skills so that I can be more confident about the solutions I produce. Essentially, I wanted to feel smart enough to compete with all the senior developers on the market. However stupid this sounds to me now, that was my goal at the time. I have read a lot of books, watched hours of presentations, started a blog and much more since then. Here are my biggest lessons learned in the last year and an update on my future educational goals.

Don’t Fight Your Tools

My first target during the year was mastering writing clean code. I’ve read Clean Code and The Clean Coder, watched over 30 episodes of Clean Code videos and read stuff on Uncle Bob’s blog every day. I was fascinated. One very strong delusion that stuck in my head for a long time was that frameworks like Spring or Hibernate are our enemies. They spread across your application, scattering around tons of annotations, base classes and unstable APIs, breaking things with each version update, slowing down your tests and obscuring your real intents in code. I wrote several blog posts about it – some got deleted, one is still available on DZone and I hope nobody will ever find it again. Several people mentioned to me that my approach was too radical and impractical (and Uncle Bob probably didn’t mean that), but I “knew better”.

It took until August, when I realized how stupid that was. When reading Domain Driven Design (the best book I’ve read in the past year btw.), I was impressed how Eric Evans presents trade-offs between efficient usage of Java EE APIs and still maintaining a clean, evident reflection of the model in the code. This was the moment I changed my mind for good. Frameworks and other tools save us a ton of time and we should learn how to align their usage with our needs, not actively fight them.

You’re Paid To Provide Value

My clean code, TDD and DDD fascination had its good sides – I learned a lot, I grew my blog, I spoke at 2 JUG meetups. But it also had a downside – I was so concerned with creating the perfect solutions that I often couldn’t decide on anything and ended up with suboptimal solutions. I was able to spend hours thinking about and discussing things that did not matter at all. I felt unproductive.

At the time, I was reading a lot of blog posts about software consulting and strategic topics like architecture, refactoring vs rewriting etc. A lot of these posts seemed unpleasantly pragmatic – you do what brings the best outcome to your employer/client in a reasonable time range. Yes, you keep the code clean and manageable, because you need to read it in order to work with it. Yes, you align with conventions and best practices, because you don’t want to reinvent the wheel. But you don’t spend majority of your time perfecting the code that is good enough! You don’t overdiscuss little things! In the end, what you want to maximize is the value provided for your client, not quality of the code that is already good enough.

It’s About People

The third big lesson was about Agile and OO. At the beginning of the year, Agile for me was a bunch of different approaches to organizing developers’ time. You want bigger, planned chunks? You go for Scrum. You want a continuous flow of tasks done? You go for Kanban. You don’t really know what you’re doing? Call it Scrumban. Object orientation was merely a characteristic of the languages that supported polymorphism and encapsulation. Then I watched this presentation.

Until recently, when I read the original Kay’s document, I haven’t followed it up with any additional reading or anything. But it made me think. It stuck in my head! My job stopped being about the code I write, about the tools I use or about new technologies. It’s about understanding people. capturing their way of thinking about their problems and solutions, and reflecting that in software I create. Maybe the code I write hasn’t changed too much since then (yet), but the mindset change was substantial.

What’s Next

Here’s today, 2017 already. I’m looking forward to further exploring the original ideas behind object orientation and Agile. Next two books on my reading list are Lean Architecture and Mental Models (I won’t share more, because I regularly shuffle the list). I will definitely explore more about DDD, as I still need to finish reading Implementing DDD by Vaugh Vernon. In general, I want to read a lot of books and grow a lot, and that’s what I wish in 2017 for myself and for you!

About the Author Grzegorz Ziemoński

King of Tidy Java, nerd that thinks about producing perfect software all the time and proud owner of 2 cats.

follow me on:
  • Jacek Bilski

    Hi Uncle Grzegorz 🙂
    I must say, that we’re taking a very similar learning path. And I think, that you’d agree with me, that it’s quite a ride. At least it gave me a lot of fun, but also enabled me to understand things. I had the same thoughts about Spring and Hibernate, I’m at peace with Spring now, but I might not like any ORM ever again, we’ll see. And I couldn’t agree more, that it’s about adding value and a key to achieve that is people.
    And don’t worry, you’re already within top 10% of best developers, this year we can attack top 5% 😉
    Good luck,
    Jacek

    • Haha! Hi Jacek!
      Indeed, learning all those things is exciting. Can you elaborate your concerns about ORMs?
      Thanks and Good Luck too!

      • Jacek Bilski

        From my perspective they’re creating more problems than they solve. I mean, how much configuration do you need to get Hibernate to work (Spring Boot apart)? And for what? For persisting data objects, that are not even your main objects you work with. Simple JDBC call can do it. Plus, not that we’re doing this yet, but I’d be more willing to go for event sourcing. This is actually much more closer to the real world, your applications usually react to something that happened (aka events) and it’s those events you want to store, not your state, which ORMs are mostly doing.
        Of course, this is all oversimplification, but going domain driven and stop putting a DB in the very centre of my applications, but ORMs provide less and less value to me. Then again, it might be just the fact, that what I’m working mostly with is calculations, data processing, decision making, my application do not own the data.