I feel the need to brag a bit. Recently, my employer upgraded my dual monitor setup to a couple of Dell 27” monitors. With a resolution of 2560 x 14440, I have tons of space to spread out my code. The old adage says that bigger isn’t always better, but when it comes to monitor sizes, I have to disagree.
Anyone who has done any Java development in the past 10 years or so, have probably used Maven to build your applications. If you’re old enough to remember building things with Ant, you know that Maven dependency management is a definite improvement over manually managing your application’s libraries.
But over all these years that I’ve been developing with Java, I’ve noticed that people tend to get tripped up because they don’t really understand how Maven dependency management really works. The rules are actually quite simple. Once you understand them, Maven seems a lot less scary.
Do you write tests? Maybe you even practice Test Driven Development (TDD)? Are you spending the time to do proper design? Are your systems rigorously monitored? These are all important disciplines in the field of software engineering. It can feel onerous to follow these and other practices, but doing so will actually make things easier in the long run.
What exactly is software architecture? We, as developers, talk a lot about it. But what does it really mean? Architecture is a word borrowed from the building industry. It is the art and practice of constructing buildings. Software architecture, by comparison, is the art and practice of building software systems. If you think about the practices associated with building architecture, there are many parallels to software architecture.
There is a staggering amount of new technology out there. In their last report, GitHub claimed they had 19.4 million repositories. Netflix alone has 124 projects in GitHub. With all these new projects out there, it’s tempting to try and use it all. But you must resist.
The more I work with microservices, the more I realize that many of the patterns used for Object Oriented Design (OOD) can be applied to the development of microservices. Whenever I get stuck building a microservice, looking at it from the point of view of OOD principles seems to help enormously to get me un-stuck.
Do you feel like your ideas are being ignored? You can pound out code with the best of them, but somehow, your suggestions fall on deaf ears. Maybe you think that if you just write quality software, your work will speak for itself. I certainly fell into this camp.
Here’s the scenario: You’re writing a REST API endpoint. Like a good programmer, you want to handle error conditions. “What happens if the thing isn’t found?” you ask yourself. You consult your favorite HTTP status code reference. “Ah-ha! Status code 404 means ‘Not found’. I’ll return that.” You code it up, write the tests (or the other way around, for you TDD enthusiasts). Off to production it goes.
Job well done!
And then your system monitors start going off. The on-call person calls you and wants to know why there is suddenly a spike in errors.
Your colleague gets a promotion. The team is celebrated for finishing an important project. An award is presented. What inevitably happens? The long hours are highlighted. The team or individual is rewarded for coming in early and staying late. Pulling an all-nighter to finish the project really paid off. Way to go team!
Unfortunately, this celebration of overtime, of rewarding working extra hours, sends the wrong message. Not only that, it is counter-productive and hurts morale.
Do you remember, back in school, that kid who was always complaining? The cry-baby? The one who was always asking questions like, “Why does he get all the breaks?”, “Who blew the curve this time?”, or “When will Mr. Johnson cut me some slack?”
That kid didn’t go anywhere. He just got taller.