DEV Community: TheWizKid

Good code is like an onion, it has layers

TheWizKid — Tue, 11 Oct 2022 13:17:39 +0000

The stack — Java, GWT, Mysql

The Experience — 11 Years

The Job — Senior Developer at Startup

—

Teaching some new recruits

It was my 3rd year at the startup, things were going well, the company was growing. We needed more working hands, so like any company, we hired a new group of devs, straight off the assembly line (because why spread it out, or get someone with experience). I don't exactly remember how it came to be, but I was in charge of getting them up to speed. This was my first true taste of teaching and leading.

I was always good at winging explanations, and presentations, so it was no different here. I showed them the ropes, the way things were put together, and what talked to what and how.

The problem came when I needed to explain the way the code was written, and why it was written that way. We were using GWT, and for those who don't know, it allowed us to write the client code as JAVA and use the same entities as we do with the DB.

To say that it was useful was an understatement, but like everything in life, this had its drawbacks. Namely everything you save in the DB is sent to the client. This could and did cause many performance issues, and looking back I'm pretty sure there were security issues stemming from this behavior. This code was not layered correctly, but I didn't quite know it yet.

The code that forced me to look and understand layers

It was around this time that my friend started working on another startup, there he worked with this outsourced dev. She had written the main structure of the server code, and had very distinct layers and separation.

I try not to go too deep in technical terms in these posts, but I kind of need to here. There are a few different actors in our story, and each has some specific needs and talents.

The DB

The job of the DB is simple, save the objects you need to, and allow you to query them when needed. So naturally, this is where you need to think of how to save things, how they are connected to the other entities in the system, and how you are going to query them.

The Server

Its main job is to process things, take requests from the client, do some logic, and save it to the DB. This is the man in the middle, between the client and the DB.

The Client

This is where things are displayed, not everything you need to do the job needs to be displayed. Sometimes you want to display things as a mix of other things.

Now I want to focus on the server, this is where my expertise is, and this is where the layers are most prevalent. It's the server's job to get tasks from the client and process them, update the DB, and send the results back for display. Let's break this down into meaningful layers.

[API] ← RO (Representation Object)→ [Service] ← Entity/RO → [Handler] ← Entity → [Dao/DB]

The client does requests against the server, this is deserialized to a RO.

This RO is then used by the service to do logic, this is where processes are done.

The service in turn works with the handlers, where short and transactional logic can be performed.

They in turn can use the DAO (Data Access Object) to persist and fetch data from the DB.

I'll dig deeper into the different layers, and what they are in charge of, and why they use the Objects they do to talk to the other layers.

The API

This is a facade, facing the client. Not all data needs to be transferred in order to do the requested action. For example, there could be fields on an object that are immutable, and there is no reason for the client to send them over when updating an object. Or there could be fields in the server that are only required for server logic, no reason to send them back via the API. This is why this layer works with ROs aka Representation Objects. They can have less fields, or aggregated fields, that can be used by the client.

This layer should be kept as “stupid” as you can, allowing the system to have multiple different types of APIs that call the same logic. The logic is based on the Service layer, and the API calls upon that layer to achieve its goals.

Service Layer

This is where most of the business logic lives, the different processes that constitute a system. These processes can be long, and can require multiple entities within the system. It's the service layer's responsibility to map the ROs into something more useful for handling the logic.

The service layer calls different Handlers, each with its own domain of responsibility to run the logic. These processes can be long, and should not be transactional (Create locks in the DB).

Handlers

Handlers have very well defined responsibilities, they usually work with only 1 entity, and they are the ones that can do transactional actions. They are also the only ones that talk to the DAO/DB.

As you know, DB transactions can cause locks. One of the things we strive for in good system design, is to minimize lock time and scope. This is why the handlers are separated from the services. In the handlers is where you will find the code most optimized, and single goal oriented.

DAO/DB

This is where persistence occurs. This layer is similar to the API layer in that it should be as simple and “stupid” as possible. Correct implementation of this allows us to simply (relatively) change DB by just re-implementing the DAO layer.

An example:

Lets take for example a process of publishing a new version of a post. This process is triggered by a request from the client, all that is needed is the post_id and version_number. So we have an RO with those fields only.

The process starts with some validation

Does that post_id exist?

Can the user requesting the publishing perform that action?

Is there a version_number like that?

Is it already published?

You can think of some more….

Now of course at the end of this, we want to transactionally update the is_published flag at the same time on the old version as the new. But during the time we are doing validations there is no reason to open a write transaction in the DB, and lock the entities. It is much better to do the validation process, call the handler just to do the swap, then continue after the transaction to create the result for the client.

This way we gained a few key points.

Shortest transaction time possible.

No connection to DB used if the request fails in the validation phase.

Code reuse - the method that publishes in the handler can later be used by different services (for example an automated time publisher).

Clear single responsibilities for each layer.

Practice what I preach

Over the years I have honed this layered design (I will get into it in later posts), but the basics remain. This code forced me to look at my code differently, and implement the layers, and I have to tell you, this has made my code much more readable and maintainable as well. It has also increased my development speed, because I can write each layer's interface, and then start filling in the methods.

I won't lie, it took me a while to get used to working this way, and even longer to get it right (I would put things in the handler that could have been in a service and split among multiple handlers), but it's a process. I urge you to try and split some code you are working on using these principals. Everyone has that 1 method that is so big that nobody wants to touch it. Go ahead, give it a go, I'm confident that after some time (and banging your head against the wall) you will be able to split it up and have much better code at the end.

Please check out my open source library and maybe even star it. I would appreciate it greatly!

My First Real Job

TheWizKid — Tue, 06 Sep 2022 13:24:33 +0000

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.

Generalization is a powerful tool

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!

What I learned in Uni

TheWizKid — Thu, 25 Aug 2022 13:21:09 +0000

The stack — C#

The Experience — 7 Years

The Job — Uni Student + Freelancer

—

My first paying job

Let me set the mood, poor uni student, first year physics major, tooo many courses at the same time, not enough sleep; I think you get the idea (and possibly what it feels like). Now I know we would all love to have some money, to go out with, and enjoy our time. We can all find some minimum wage 9-5, but I was looking for something better, and thought I could use my skills as a developer to land some work.

Luckily for me, a family friend was looking for someone to develop something for them. The job was a good mix of my knowledge and skills. This friend owned a factory that builds custom water treatment and purification equipment, and he had a bottleneck in his quoting division. Every quote the sales team needed required an engineer to write up plans, then someone needed to calculate not only the costs of the different parts, but things like length of welds, amount of paint needed, amount of bolts needed, and so forth. Till this point it was done in excels with lookups and required a lot of know-how.

My job (should I choose to accept it) was to create a visual tool, that the sales agent can drag and drop to the parts needed, including piping and such, and the output would be a detailed quote, including everything mentioned above and more.

Working with/for a client as a freelancer

Now for all you developers out there, I'm sure you are thinking, “OK, he got some requirement documents on how/what to build”. That couldn't be farther from the truth (and surprisingly more common than I had expected). I had to basically interview all the people involved in the company, to try and get a feel of what was needed. After that I would sit down and write my own basic requirement documents, that I would then go over with the client.

If there is one thing you take away from this: “Always go over the requirements with the client in writing”

This has saved my @$$ many times.

It took some time learning how to deal with clients, and I learned a ton. This first client helped me learn, the development skills aren't the only thing important, it is important to understand the clients needs, pain points, and where to focus my efforts, this has rang true throughout my career.

I was lucky (in a sadistic kind of way) that my first client had no idea on how to write requirements, and how to handle a development cycle. In the years to come, I would receive many “requirements” of the type “put a button there that does that”; and 9/10 times there is a better way to do things that answers the clients problems in a better way. I urge you to look at anything you are developing, and try to understand the business use case behind it, and look at the bigger picture. You will be surprised to find that this will help you tremendously write better code.

Just for an example, I was told to make a button for export of the quote, sounds reasonable enough, but then it would be the sales agent's job to send copies to the client, the management, and the project manager. I wouldn't have known this if I just would have developed the button. Instead I suggested that the system have projects in it, with the project managers info, and have a “send to email” button. This may seem minor, but after talking to the CEO I found out it saved him tons of heartache, because more than once, the wrong quote was sent to the wrong client, just because the agent attached the wrong file.

What you can’t learn in Uni

During my time at uni, I learned a ton of things, in many different subjects, including programming. A few caveats to this is the fact that most of the time, the languages that were taught were out of date, and the professors didn't really know how to program a product, more like write blocks of code. Sadly there is more truth than I had hoped for in the old saying “Those who can't, teach”.

I think I can confidently say I learned more in my first freelance job, then everything uni could teach. There is nothing like getting your hands “dirty” and just doing some work. Here is a small list of the top things I “learned on the job”:

Understand the business - Like I stated before, understand “why” your client needs the feature, not just how they see the feature implemented
80/20 principle - Try and spend your time wisely covering most of the needs, and leaving “known issues” for the really rare edge cases.
KISS - “Keep it, simple stupid” (or sometimes I think it’s “Keep it simple, stupid”), try to simplify your code, break it into smaller bite sized pieces, that will pay dividends in the long run.
Performance isn't everything (or even important most of the time) - Today's computers are fast (like really really fast) and that fancy Binary search algorithm you learned, doesn't really matter in real life (most of the time), when you filter a list of even a few 10s of thousands, it’s not really going to change the runtime.
Use open source wherever you can - There are so many amazing open source projects out there, and they can cut your programming time by a huge factor. Additionally they can (usually) do it better then if you tried to write it yourself.

Please check out my open source library and maybe even star it. I would appreciate it greatly!

They don't call it intelligence for nothing

TheWizKid — Wed, 17 Aug 2022 14:20:08 +0000

The stack — C#, Oracle

The Experience — 4 Years

The Job — The intelligence corps

It's my time to serve

This may be doxing myself a little, but where I live there is a mandatory military service, for 3 f%$#ing years. Luckily for me, I had some skills, computer skills. It works here like this, you go do a lot of tests, intelligence tests, aptitude tests, physical tests, and at the end you get stationed somewhere (usually NOT where you want to be). I was in the running for a few different positions, and then one day out of the blue, I got a phone call. Come now to interview for a new position, nothing that I ever heard of, well of course I went. They were looking for someone with programming experience that they didn't need to send to the military academy to learn, and I fit the bill…

One thing led to another, and within the week I found myself in basic training on my way to the intelligence corps, as a developer in a small unit. After a few weeks of basic training (even us developers go through boot camp), I arrived at my unit. This is where I found out that just me and 1 other guy are the only people in the unit that can “speak computer”, and no I don't just mean program. We were in charge of the whole system there, from the network, to the servers, and of course the software.

How to learn C# in 3 easy steps

Get enlisted to the military, to a plush desk job as a programmer.
Be 1 of 2 people in charge of the whole system.
Never forget that if you don't get on top of things within a few months, they will ship you out to somewhere much worse.

Easy right?

But in all seriousness, I had to teach myself C# on the job. At least I had the running code, and the coveted PC on the internet. You see in the intelligence corps, and probably most military installations, no one has internet access on their PC. Well technically neither did I, but what I did have was access to the only PC (that was air gapped from the network) which had internet access.

By this time of my life (luckily for me), google was a thing already, and there were more and more resources online about programming. Even more for things like C#, because it was Microsoft's. But (I hate it that there is always a “but”)… The computer in question is air gapped, so no copy paste.

Into the deep end

This was the first time I truly worked with a DB (I don't really count MS Access). It was my first time, and they threw me into the deep end (without floats). Our systems used Oracle, till this day I think it's an amazing DB, but it's a beast. Our system was complex, and today, I would have never built it this way (I didn't build it back then either, the system was operational when I got there).

I know I'm going to spark some debate about this, but I dont think business logic is supposed to be in stored procedures (there I said it). This architecture caused some very weird side effects, for example, releasing versions requiring simultaneous release of new stored procedures, or updates to old ones. Triggers that can cause chain reactions of events, and you can't quite see them in any IDE.

If that wasn't bad enough, we didn't really have a server side. The C# was a desktop app, installed via group policy to all PCs on the network. The server was basically the stored procedures in Oracle. So things like creating thread pools to handle large tasks, or locks on editing were all out of the question.

This is where I started thinking about how code should be built, and it was the start of the path to architecture. Even if it still took a few years to find out what I should do, at least now, I know what I shouldn't. It was an important realization, one that I have since seen on some of the juniors I mentored. Writing code without bugs is important, but writing code in a maintainable way, is just as important.

My partner in crime

About half way through my service, the other guy I was with finished his tour. It was up to me to find a replacement. I had access to candidates (and it's not like they had CVs, they are all 18 year old fresh out of high school), I gave them tests to do, asked them questions. Remember back then I couldn't send them anything online, all by phone, or in person.

After a few weeks, and at least 50 candidates, I had found him, my new partner. Again we couldn't send him to learn in any course, so I had to find someone with the knowhow from home. Additionally even after I selected him, it took months for him to get to me. He had to get security clearance, and go through boot camp. So months later he was finally here, I would like to introduce you to a new character (that will have a recurring role in the articles to come), my business partner (and best friend).

Like any relationship it was rocky at first. I won't go into the details, but what I can say is that we went through a lot together. Things that built our relationship strong. Little did I know (spoilers) that we would be working together till this day (over 16 years).

Please check out our open source library and maybe even star it ;-)
We would appreciate it greatly.

So the journey begins

TheWizKid — Wed, 10 Aug 2022 12:52:04 +0000

The stack — VB6, C
The Experience — 2 Years
The Job — High school

Isn’t learning fun?

To set the scene, it was early 2000s in a small farming village. Yes we had internet, but it was dial up, and no stack overflow or anything close yet, the best you could hope for is a forum post.

So how did we learn? TL;DR — Books and lots of them…

I remember going to the library looking for books, swapping with friends. If you got the expensive ones you even got a CD (you know the round thing with a hole in it) with them with code examples and lesson projects, not that the CD ever worked (or was even there) from the library. No searching the book for your problem or an example, no copy paste, nothing. Just read and hope you remember later where you saw something about that problem you are having.

Yes the internet existed, but there wasn’t much in the way or programming guides, tutorials, or even examples. One of the most useful tools was IRC channels (for you kids out there, a really old chat). Tell you the truth, I don’t even remember how I found what channel to write to, but I remember talking to people from around the world about the most silly things, things that today you will find the solution to as the top search result on google.

I know this is weird, but you can learn at school

When I reached the last year of high school, I took a tech class. In this class we learned things from electrical engineering basics, mechanical design, and of course programming. The main problem was, I had taught myself more than what the teacher reached in class. Nonetheless I gained a great resource, my teacher could answer questions, point me in the right direction.

First of all, I would like to say, not all teachers are bad (yes many are, but not all). Luckily for me our high school tech teacher saw my potential (especially after I broke the school’s network). I used to get bored in class, everyone was learning C and VB6 at a level I passed a long time ago on my own. That is when my teacher came to my rescue.

My first real project

Computer vision, you know when computers look at an image and try to understand what is there. Well for that time it was no AI models or anything, it was purely algorithmic. My mission should I choose to accept it (over being thrown out of class) was to take this “new” library that allowed me to capture an image from a webcam in VB6 and process it (pixel by pixel), and try and make out a shape in an image, simple geometric shapes (circle, square, triangle).

So my best friend and I set out to this task, it was soooo interesting we would have all nighters trying to solve it. Let me take you through the basics.

Go over the image one pixel at a time to try and find a place with a big change in color (black shape on white paper).
When I reach it, go in a pattern to find its neighbor that is also a border pixel.
Do this in a loop till I can’t find any more border pixels.
This worked (in theory). There is always a “but”… It all went to hell when we would hit these edge cases of a few pixels out of place.

That’s when it hit me, the solution may be obvious to you, but to me it wasn’t. Well, it turns out there is a use for the data structure “stack” we’ve been taught. We put all pixels in the stack, and each time we would hit a brick wall, we would pop a pixel and try again. This would continue till we popped them all out and got back to our starting pixel.

This turned out to be very effective, and solved our biggest problem.

We actually found a few solutions for understanding what shape it was.

From the trivial, see how many “straight” lines made up the shape, which worked pretty well for simple shapes. To the most advanced solution, that I am still proud of till this day, calculate the area of the shape, and the perimeter of the shape, and see what constant best defines the relation.

The moral of the story

I told you this whole story to come to a small point, one that shaped the next few years of my development life. Data structures & design patterns are there for a reason, and even though it might not be obvious, you ask yourself “why would I ever need that”. At some point you will, and it’s good to keep them handy.

If you would like to check out our open source library and leave feedback we would appreciate it greatly.

The story of a Noob

TheWizKid — Thu, 04 Aug 2022 07:42:00 +0000

The stack — VB6, Macros, MS Access
The Experience — 0 Years
The Job — Start of High school

Where do I even begin?

Like I stated in the prologue, I was fascinated with tech from a very young age. What I failed to mention before is that thanks to my loving and understanding parents, my curiosity was not killed in school. That’s mostly thanks to the fact that in my house I could always take any “junk” home to take apart and learn how it ticks.

My first steps

At the age of 13, I was already pretty good on a PC, but haven’t really dived into programming yet. My first real time was when I went to a few VB6 classes and convinced my parents to buy me a book.

For me it was like magic, I could tell the computer what to do and it would do it, as long as I didn’t fuck it up somehow (which happened a lot at that time). I wrote small dumb things, what most would call a “Hello World”.

I’ve been a bad boy

It was around the my second year of High school when I noticed how bad the computer system at school was, how weak the security was, and of course I had to find out if I could beat it. But being the goodie two shoes I was, I was scared to do it, and if it wasn’t for the fact that the guy in charge of said system told me I was wrong (he thought it was secure), I wouldn’t have even tried.

So I did what had to be done, I got hold of *.pwl files (win 98 password files, and yes I am a dinosaur), and found out how to crack them. I wrote my first brute force script and made all the PCs in class run it at night. Luckily for me the password was short and within a few weeks it was cracked.

You have got to start somewhere

Yes I know what you are going to say, what a geek, nerd, … Yes, I spent my free time teaching myself programming. No, I wouldn’t change that. I’m not much of a reader (till this day I can’t read for fun), but somehow going through a programming book was not a chore and I learned a ton. I think the most important part was that it interested me and I was passionate about it.

Today is different, but I highly recommend to anyone to just give it a try, go take a course online, or use YouTube, or even just go though GitHub. Today it’s sooo much easier and more accessible. Who knows you may just find that programming is your dream job.

If you would like to check out our open source library and leave feedback we would appreciate it greatly.

Prologue — One devs journey

TheWizKid — Thu, 04 Aug 2022 07:37:00 +0000

A brief history

It’s rude not to introduce myself, so I’ll start with a little background, just to get us started. I can call myself a developer for over 15 years now, and a tinkerer for a few more. I started playing with technology from the very young age of 7, when I entered and won a race event where I built a toy solar car. Till today, as a system architect and having some successes (and failures) at tech startups, and running my own dev & consulting business.

What’s the point of all this

As of late, my team and I have released the first of our libraries as open source, this has made me look back at the path that led me here. My main goal is to share that story, the ups and downs (and sometimes sideways) and hopefully it will help someone on their path. I can’t promise it will be interesting all the time (or even pretty), but I hope you will join me for the journey.

I’ll try and keep it brief

I will be writing this as a few different posts, each one not much longer than this one, as I want it to be a quick and fun read. So this is the plan:

The story of a Noob — My somewhat humble beginnings
The journey begins — Teaching myself in the age before google
They don’t call it intelligence for nothing — My military career
School can’t teach you everything — My time at Uni and my first freelance work
It’s time to settle down — My first real job
Good code is like an onion, it has layers — The right way to write code
My eureka moment — After writing the same code over and over, something had to change
It’s ALIVE — My solution to CRUD boilerplate, and the evolution of the layers
Shit just got real — Using what I learned to land a big contract
Time to give back — The birth of my first open source