As one might have imagined, MetaBroadcast isn’t only about cakes and metadata. There are some solid engineering principles behind our code, and developers are really encouraged to learn, suggest enhancements, and overall, be bold.
hitting the gas
Or perhaps I should say petrol, considering we are in England? Anyway, getting up to speed in a new job is not always the simplest of tasks. I must admit that joining the team is doing me some good, as the completely different nature of MetaBroadcast business and the adoption of a post-agile methodology have led me to several moments of epiphany.
lessons from stand-up comedians
The other day, I was telling a joke I heard in a stand-up show which I thought was a riot and that my friend would enjoy as well. I ruined the joke by laughing throughout my delivery, making it difficult for my friend to even understand what I was talking about.
Sometimes code is like that. While fluent interfaces are not new to me, their use outside of builders was something that never really occurred to me until I saw the pattern in our code and inquired why we had so many classes that looked like builders. Now it all seems quite obvious, but those like me used to having getters and setters everywhere, know that it’s uncommon to see ‘with’ instead of ‘set’. Maybe it’s because so many frameworks rely on them, such as Spring and Hibernate. Eclipse even writes them for you!
clear your mind of all thoughts
Nothing is an abstract concept. How should one deal with it? Or as Fred has said: Null is not a message. Then there’s Guava’s Preconditions. Simply put, preconditions validate your input and fail fast, making potential bugs more evident quickly.
the joys of integration
Perhaps I was suffering from the disease to please, which is so common with new joiners, but after my first complex task, namely migrating one of our systems to the Twitter API 1.1, I realised I’ve not been inquisitive enough and I’ve been pretty much taking a lot of things at face value.
But every so often, I question myself about the old saying: If it ain’t broke, don’t fix it. The problem is…
… to boldly go where no man has gone before…
… one has to take risks. Of course improving something costs money and/or time. But usually, the pros of fixing something obviously wrong trump the costs. With that said, I’ve recently been told: “You should be bold where you see potential problems or you create more for the future.” This encouragement to make changes, even if something’s working is definitely uncommon for me.
The fact I’m learning a lot more than the codebase, makes me wonder if I froze in time the moment I joined certain companie$. With so much I’ve been learning here at MetaBroadcast, I’m wondering if this is the company where I’ll reach programmer’s Nirvana.