Starting a Java Blog

Hello World!

One of the first programs that new developers is, inevitably, a 'Hello World' program. This is a classic in Software Development that introduces a new coder to a new language, or a default template that shows everything is working right, or any number of things. This blog post is my own 'Hello World' to the idea of blogging. My goal is to introduce myself, mention a bit on my experience and how I've gotten to this point, and to set a beginning point on what all kinds of things this blog will be touching on.

So, first off is introductions. The fly-by version is that my name is Alex, happily married to an amazing wife, and currently have 3 amazing daughters ages 4, 3, and 1 (at least at the time of this writing!!).

I began my software development career by attending Purdue University's Computer Science program, and graduating with a BS in Computer Science in 2010. From here, I started my first full-time job with my degree working with a consulting company for a very well known company (I probably won't disclose anybody that I've worked for). I worked on a legacy application for 6 years for my first project. I didn't know any better at the time, but looking back I can see what it was like working in a legacy system. The basic architecture was HTML/CSS/JS front end and Java back end. The data layer was using a product called Enovia (for anybody interested in that kind of thing!). This thing was all custom code, and it was massive. If memory serves, the largest class was 20-30k lines long, just to give you an idea. It was, at times, painful to work in, even though at the time I didn't even realize it. It was just myself and a tech lead that had worked on the application since it's inception, plus a few offshore developers that worked on various things from time-to-time. Obviously, we wore all the hats. We would gather requirements, code, test, deploy, etc. etc. It was my first taste of an enterprise-wide application.

For the next year or so I was a contractor for the same company, but had switched teams. This time, we were working on a lot newer tech stack. It was just myself, a co-worker, and some offshore developers still, but it was all fresh features. I came on board just after the application went to production, but it wasn't used a whole lot yet. It was written in Angular 1 for the front end, and Java for the back end. We used WebSockets to pipe real time data into our application for the end users to visualize in different ways. It was fun and exciting compared to working in the legacy system, and I continued to grow. But, I still had a long way to go (and still do to this day!).

With both of these first 2 applications I had grown a lot. But, the quality of my code was very, very poor, even though I didn't realize it. Obviously I would try to use objects, inheritance, polymorphism, and other cool words that I learned from my college days. But, the name of the game was FEATURES. Get more functionality out to the users as quickly as we could. We didn't have any automated tests, everything was ad hoc by our development team, our product owner, and maybe a couple of end users. I don't recall writing a single unit test for the first 7 years of my career.

Then, everything changed. My family moved states so that I could work for an amazing company. It was much smaller than where I was at before, but the culture there was top notch. This group of developers cared about the quality of their code, and treated it like their craft. It was not just about doing something. It was about doing that something the right way. It was thinking about doing things in a way that wouldn't slow us down if requirements change (which they do!), or if we needed to add/extend functionality, or needed to scale up more. Basically everybody there had a copy of Clean Code, and actually used and referenced it while coming up with solutions, instead of just having it sit somewhere on a dusty bookshelf. It was here that I learned the importance of unit testing, Test Driven Development, design patterns, QUALITY. Also here we had code reviews for any and all code that was written. It wasn't just a rubber stamp signoff. It was used to make sure things were done thoughtfully, for using the right design pattern, to the names of variables. I grew more there in a 1 1/2 years than the previous 7 years combined.

But, alas, things change. We decided that we needed to move back for a while to be around family. I truly miss the culture that I had grown to love, and hope to return to in the future. I am now at another very large company, and have been here for 6 months now. Although a very different culture yet again, I am still excited about what I can bring to the company. And, as always, this new company comes with its own challenges to overcome. I'm having to expand my skill set by working with multiple teams across multiple applications, having coordinated releases, and working with a much larger team with different development backgrounds with different styles.

I guess that brings me to why I am writing all of this. After seeing and feeling what it was like to work with a company that has high code quality, I want to pass on the importance that has in our field. Much to often we are against deadlines where quality will slip. Management always wants the projects completed yesterday, and developers start to cut corners and sacrifice quality. A copy-paste here, leaving commented code there, pushing off unit tests for another day that will never come.

The aim of these blog articles will be to equip you with knowledge on how to write code the right way. I'm planning on starting off with a series of blogs about different design patterns. This will help me out with learning the ropes with blogging, while giving you readers some tools to add to your toolbox. Then, more of the "fun" posts will come. Things that are not as clear cut as explaining a design pattern. Some might be controversial topics that are debated back and forth on which was is better. Things like whether it is better to throw exceptions or return error codes (Hint: I am in the camp of using exceptions!). Small disclaimer: I do not claim to know all things, to be a defacto expert on all things, or anything of the sort. These blogs will be my opinions, understandings, and views based on what I've learned, used, and prefer. That said, any code that I use as examples are of my own creation.

I look forward to writing out these blogs, and hope that I can pass along some tidbits that will help you become better programmers!!

-Altash