The stack — Java, Mysql
The Experience — 9 Years
The Job — Junior Developer at Startup
—
My first job interview
In my last year of uni Aviv (my now best friend and business partner) told me he is working at a startup that is now growing, and I should join him working there. I was nervous for my first job interview, they were working with a different stack than I had experience with, and let's just say I'm a little weird. A little background, I live and had grown up in a rural farming area, I wear shorts, and sandals (even in the dead of winter), not exactly “professional” looking. Anyway I vividly remember taking long pants and shoes in the car with me to the interview, thinking I would change right before I went in, to look the part. At the last moment I changed my mind, and told myself, “You should not try to pretend you are something you are not, they will either take you with your quirks or it's not the right place for you”. So I walked into the interview with the CEO of the company, in shorts and sandals. Lucky for me, the CEO was wearing torn jeans, and dirty worn sneakers, I felt right at home.
All this was to say something simple, but not easy. Be true to yourself, if you go work somewhere you won’t give your 100% if you feel out of place. I'm not saying you need to reject any job that isn't perfect, it's more like, find a job that doesn't compromise on your core, and be flexible about the “less important” stuff. In the long run this will be much better for you and the company.
Java you say
My first day on the job was an interesting one, I got to the new office, they gave me a laptop, and told me to install my environment. Easier said than done, till now it was a visual studio, now I needed this weird eclipse thing. Then I got the code and nothing runs :/ weird. After some back and forth, I learned that for java and eclipse I need to download the JDK (Java development toolkit), fine. Still nothing… Just a reminder it was my first day on the job, in a language/stack I didn't know, and I didnt want to be the new “idiot” they hired. Safe to say it took me the whole day or maybe even 2 just to get the code up and running.
Later that week I got my first task, I needed to copy some functionality that existed in the client area to the back office. This was actually a perfect first task, for many reasons, most of all it was 70% copy paste. This was great because I had barely knew how to read the java code I was looking at. Additionally the adaptation needed in the back office project was simple and existed in one form or another in different areas of the code. So basically the task was like a big jigsaw puzzle, I got 1 big piece, now I need to go hunt down some smaller ones and put it all together.
A small tangent
Over the years this “jigsaw puzzle” approach has really sunk in, and today I can tell you with confidence, if you structure the tasks given to developers (especially juniors) in this way, a few good things happen:
- They get into the code much faster.
- They write less buggy code.
- They build confidence in their abilities.
Finally as a business owner I can tell you from my experience, it takes a lot less time to see a positive ROI for their time.
This has led me to a core belief of mine (in regards to development). A good programmer needs to know 3 things:
- How to read and understand code.
- Be proficient in google searches for solutions to the problem at hand.
- Know how to adapt other code to meet their current needs.
A great programmer is one that knows how/why things are done in this way, and understands optimization and deep diving into frameworks they use. While a good programmer just needs to know how to use the framework, and not how it works.
What is this Spring magic - using frameworks
The project we were writing was built upon Spring (a hugely popular dependency injection framework in Java). Now frameworks are powerful tools, but they hide many things under the hood. Over the years I have learned in depth how/why Spring works, but truth be told, as a junior developer back then it seemed like magic to me.
I want to take you through a few different stages of understanding that I use today when I am faced with a new framework.
Step 1 - Basics (The what)
In this step it is most important NOT to try to understand how it works, just to understand the tools and capabilities it provides. I have seen it many times that a junior gets “stuck” on trying to understand the depths of the framework, and the truth is they are just not ready to. They don’t fully understand WHAT the framework can do, so they have no chance to understand how.
Step 2 - Advanced Usage (The how)
Almost every framework I have used has many different features that compliment each other (makes sense). This stage is focused on that, using the framework to its fullest. Mixing and matching different features, making the whole greater than the sum of its parts. This is where the developer truly learns HOW to use the framework correctly.
Step 3 - Down the rabbit hole (The why)
Here is where things get truly interesting. There comes a time when you reach the limits of the framework and try to do something you think should be possible, but turns out it isn't. This is when you download the source code and start the deep dive to understand the WHY. Sometimes it's something at the core of how it's built, but other times it's just on the fringes of what the framework can do, and that means, no examples, no documentation. Then the only answer is to understand why the framework works the way it does.
Step 4 - Building upon the framework
This is the final stage, where you can start using the tools the framework gives you to build your own mini framework upon. Or even build your own libraries from scratch. This is where you start contributing to the framework, or start releasing some open source of your own.
After a year or 2 in the company, I got a new task, implementing a new PSP (Payment service provider), basically adding something like paypal to the clients payment options. This was a new area in the code for me, something I had no experience with. So off to the races, I went and looked at the implementation of a few different PSPs, and to my shock, I saw a ton of very similar code, makes sense since it doesn't really matter how the money comes in, we still need to update billing, create the relevant logs, and credit the account. All this was done time and time again, in the different PSPs, this was mainly because the objects we were getting back from the PSP api were so different.
Interfaces to the rescue, this is one of my first epiphanies, this has led me to proper code layers, and a few “new” design patterns (really just classes that give me a mix of design patterns with no boilerplate code). So I told my boss I needed more time to rewrite it correctly, and set to work. I created a handler that was in charge of the process of communication with the PSPs. It had methods for the different actions, like charge or refund and so forth. It managed the different steps of the process and called upon the different classes of the PSP for interpretation of the response received via API.
I don't want to get into the code (this is not the point of the post), but basically there was a PspResponse that all PSPs needed to inherit from, and then methods like:
getIsSuccess()
getErrorText()
getAmount()
This took some time to refactor the old code, but in the long run reduced implementation time for new PSPs drastically, all the while reducing the amount of bugs (mainly because someone would always forget to update the new logic in some old PSP).
The experience I gained designing and implementing this led me down the path to becoming an architect. I felt so proud from my new creation, and caused me to look at code in a different way. This is a pivotal point in my career, and has caused me to think about how to write code correctly in the long run, and not just this feature.
Please check out my open source library and maybe even star it. I would appreciate it greatly!
