Hello everyone! Welcome to my first post.
My name is Jake and I have been working as a developer in industry for just over a year now (started on the 11th Dec 2017). I am writing this post in an effort to:
- give an overview of my background and what lead me to choose development.
- summarise what I have achieved this year.
- give tips for new developers on this journey based on my experiences so far.
Before my industrial development journey began, I first went to university to study Mathematics. Here is me proudly holding up (read: posing with) my project:
During my final year of my degree, I embarked on a project with Melina Freitag, with a single overarching goal: to understand and implement a simple Recommender System. If one is interested in the details, then I have provided a link to my paper here. (Fun side note: at this point in time, I did not realise that this was technically machine learning!)
Out of all of the modules that I took in the final year of my degree, I enjoyed doing this project the most. I enjoyed the research, I enjoyed the mathematics, and I enjoyed the programming. At the end of the paper is my first attempt at solving a "proper problem" using programming (so be warned, it isn't the nicest thing to look at, heavily referencing the previously mentioned paper to understand all of the variable names).
This sparked my interest, and I soon landed a position as a backend Java developer within the financial services sector.
Prior to landing the job, I started progressing through this massive open online course (MOOC) to understand the syntax of Java (as this was light years away from MATLAB)!
However, the initial transition from MATLAB to Java was painful to begin with...
- Java, what do you mean this won't "compile"?
- Java, what do you mean this isn't a
a = "word"does the trick?
- Java, what do you mean
- Writing "clean code".
- Principle of Object Oriented Programming (Meyer, DRY, SOLID.)
- Agile SDLC methodologies (Scrum.)
- Dependency Management (Maven.)
- Version Control (Git,SVN.)
- CI (Bamboo.)
... it was overwhelming.
It is these times in which one feels overwhelmed where one can start to feel discouraged. I know that I went through this process. However, through consistency and dedication, I would now consider myself to be generally competent. I have learned a great deal and I am enjoying the discipline more every single day. The reason I use the term generally competent (being very careful with my word choice here!) is that:
- I believe that no single person can learn every single thing, but
- I believe that being disciplined and consistent with a single thing and given enough time to a single thing, one can learn it.
To elaborate on this point, I now believe that given enough time about a particular area, I can continue to learn about said area or a related area.
All things considered, I think that this is the most important thing.
- It is easy to become overwhelmed with the vastness of the development world.
- It is easy to become dangerously engrossed in a problem that should be "simple" to solve.
- It is easy to feel that you need to learn this.
Take a step back. Take a deep breath. Relax. Everything will be fine. Go for a quick walk, or make a cup of tea! You will be able to solve the problem at hand, just maybe not right now. That is okay.
For me, this was a difficult transition. I did get lucky, though, as going out and performing the research for my final year project at university helped to prepare for this learning style.
Coming from a mathematics background, university was fairly simple from a structural point of view; every lectured concept builds up on previously lectured concepts in a neat, linear fashion.
In my experience, software development is the polar opposite. It's as if you have to open your mind to receive information from every direction and then make the connections later.
The main tip in this regard is just to learn things that you think are interesting or cool, regardless as to whether or not you deeply understand the prerequisites. If you think something is interesting, then you will go out of your way to learn the prerequisites (and you will already have some "information connections" for free!).
Give it time. The connections will happen (and, when they start to happen, they will happen more and more frequently).
After I started to get comfortable with the basics of implementation and design, I ended up with writer's block.
When presented with a problem, I would think about a particular implementation of the solution. When thinking about it a bit more, I would realise I didn't like this part of the design, so I re-design. Then I would find more problems with it, and re-design it, and... well, you get the idea. As a result, I would have gone about an hour without writing any code.
Instead, when presented with a problem, you should understand exactly what you want the solution to do, not how to do it.
When you understand what the solution should do, just go for it! Start your design, start your implementation, get the building blocks ready. Then, if you don't like some part of your design or implementation as you go through, just refactor!
The two major benefits to this are:
- to get more practice with the development process itself.
- to understand how to critically think about your code as it takes shape. You then start to think actively about how your code is taking shape, which in turn allows you to spot opportunities in other parts of the codebase for better design and better implementation!
One of the things I find truly beautiful about software development is the lifecycle of seeing a solution develop. The above approach yields such beauty.
I am incredibly privileged to have a fantastic mentor within my current role. A really good mentor is able to:
- understand your thought process.
- give just enough information to assist (based on your current understanding).
- ask constructive, probing questions.
If you are able to seek a mentor, then I highly advise you to do so. It doesn't necessarily need to be within your same team, or even the same firm! I find that having a second pair of experienced eyes to look at your solutions helps to make them even better. Consequently, the quality of your solutions improves and the quality of your overall development practices improves.
You are not just a code monkey. To that end, understanding your domain (in my instance, the financial services sector) allows you to truly understand what the end user requires. By extension, you will provide even better solutions thereby making your end users even happier!
In this regard, try to understand what you are trying to achieve with your application based on your domain.
For an insight as to how I learned, I did the following:
- As previously stated, I used this MOOC to begin learning Java.
- I then used Pluralsight to start to learn more about Java and OOP practices. (Note: I am not affiliated in any way with Pluralsight, but I believe it is a fantastic platform for learning).
- In terms of literature, I have read through the Clean Code series of books, written by Uncle Bob.
- I am currently reading through Effective Java.