Lessons Learned in 2016
Lessons Learned in 2016
In 2016, I learned that you shouldn't fight your tools, that you're paid to provide value, and that it's all about people.
Join the DZone community and get the full member experience.Join For Free
The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.
I started 2016 with the goal of solidifying my technical skills so that I could 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 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, and 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 for me to I realize 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 two JUG meetups. However, 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 versus rewriting, etc. A lot of these posts seemed unpleasantly pragmatic — you do what brings the best outcome to your employer or 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. However, you don't spend the majority of your time perfecting the code that is good enough! You don't over-discuss little things! In the end, what you want to maximize is the value provided for your client, not the 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 hadn't followed it up with any additional reading or anything. However, 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.
Here's today, 2017 already. I'm looking forward to further exploring the original ideas behind object orientation and Agile. The 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!
Published at DZone with permission of Grzegorz Ziemoński , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.