Over a year ago I got accepted as the Lead Software Architect at my full time job. This was a huge step up from being a regular developer.
When I applied I had minor doubts about my skills, but I also thought that I would be the best person for the job. The job description was somewhat vague at the time, and to some degree it still is, but I wanted to take it as seriously as I could.
I wanted to work as a true hands-on software architect. I didn’t want to stop being a developer all together and just be a guy who talks a lot, but can’t open up an IDE to create an example to demonstrate how it could be done. I wanted to be a person people could ask advice from and who could teach them, work as a mentor.
So, I started a personal project to improve my learning process.
Enthusiasm drives my learning
Why did I become a software developer? The answer to that question was revealed only years after I started working in the industry. However, it is something all developers know. I love solving problems.
I get a sense of satisfaction when I can get a new library or an integration working, when I create a requested feature or when I solve a bug. It is a great feeling and it keeps our work interesting.
So to get better at my job, I started learning new tools, services, concepts and design patterns, software architectures and design, but also UX and UI design amongst other things. On a day to day basis I spend an hour, or more, doing the following:
- Developing my own projects.
- Browse and read platforms like Reddit, which is a great place to pick up new tech releases and posts. You can hand pick the communities you want to follow.
- Read and write articles on Medium.com . Writing about your experiences and thoughts helps your ability to explain concepts and tools better.
- Browse current news using apps like Flipboard and TechCrunch.
- Browse many design websites to pick up stuff from there too.
- Watch talks on Youtube.
When I find some new tech ‘thing’ interesting, I might spend an hour (or multiple) researching it by reading documentation or posts about it, and then try it out in some personal project or just for fun. Personal projects are an awesome playground to test out new things.
I have no secret pattern in learning. I just read a lot, watch presentations and talks, experiment and possibly write about it. I’ve found that the greatest place to actually think about these things, and come up with new ideas, is while taking a walk or a run outside. Away from the computer.
Recently I’ve started attending webinars (as they’re mostly online now) to listen what other people on the industry have to talk about. This can give a totally new perspective on some things, or sprout new ideas.
As I look back at myself from one year ago I know I had a totally different perspective on software development. I mostly saw that one piece of software in front of me, that one platform, as that was my job back then, but now I often think about the bigger picture first. I think about fault tolerance, optimization, different tool and integrations I might need, how the code should be structured, the complexity, how we could and should test it, what options do we have, what does it cost using option A… The list of things is long.
I also feel like the speed in which I can learn new technologies and adopt them now is much faster. Having a different perspective on the terminology we use in the industry helps. Now, as I read through a Github repo with proper documentation, I can often get a grasp of what might be going on under the hood more easily.
Never stop learning
We work in an industry that’s constantly evolving, whether you like it or not. New standards get developed. New languages and frameworks become popular. A completely new way of building and deploying an application will get released, which might offer great benefits to the development process, making it faster and more enjoyable.
You’re gonna have to look outside your comfort zone to learn those. Learning those skills is what will make you very valuable to some company. I’m not saying you need to learn EVERYTHING! That’s simply impossible. You should, however, think what might be useful to you, or for your job, and try to learn those.
This is why I really like talking to junior developers. I see their enthusiasm for new tech. They have a fire for learning new things and trying out new tools which might’ve already been extinguished in more experienced developers.
Invest your time to learn new tech, or ask that your company invests in you, allowing you to spend time learning it. This investment will pay itself back.
What I’ve discovered over the last 12 months
I could create a long list of the tools, services, frameworks, concepts and other things I’ve gone through over the last year, but instead I’ve summarized some of my realizations into tips I think will help any developer.
Lean on standards
Use standards and best practices, often set by others, which have been battle-tested and proven to work. You can also set up in-house standards that you know will work for you. Learn to read RFCs .
There are also some standards to language specific development processes. One of these are the PHP Standards set by PHP-FIG. There are numerous people behind PHP-FIG with noteworthy projects under their belt that thousands of people use daily.
Strict types and interfaces
Use interfaces and types. PHP is just getting into the whole type game, and now we can write stuff like private string $uuid; which is great. This creates a contract in the code, making sure that this variable only accepts a string, otherwise it fails (so far with strict_types set).
The reason I advocated the use of GraphQL at work was because it required a strict schema to be written up front, but it also has type safety, which made sure we always received the correct type, having to avoid writing request validation. Traditionally with a REST API you have to use external tools to do this.
Another thing I now use, as much as I can, is TypeScript. The more I use TypeScript, the more I’ve started to hate JavaScript, where I can’t be sure if a number is a string or a number.
SOLID
Follow the Single Responsibility Principle. While I advocate all the SOLID principles, I cannot stress enough how you should follow this one. A class should only have one job that it does well, and it should not do anything else. This lowers your code’s complexity and makes it possible to see that if I have a PizzaDelivery class, it propably delivers pizzas instead of also making them.
Also, learn dependency injection. If you don’t use dependency injection, you are propably not writing unit tests for that piece of code.
Learn to refactor
Read through Workflows of Refactoring by Martin Fowler, or watch this Youtube talk on the subject . I kind of like that we’ve adopted this idea and the term refactoring at work after I showed everyone the clip from Youtube where Martin talks about the idea of the two hats. This enables developers to create functionality, but then switch on the refactoring hat and start changing small things which might lead to better code. I’ve often used this to write code fast, but then changed my mindset and realized I can’t unit test this, so I have to refactor it to make it possible.
Code smells are bad, design patterns help you
Read about code smells, refactoring patterns and design patterns. While even I admit I do not know ALL of then, I have discovered that it does help immensely to teach yourself a few of the most common ones to enable you to write better code. Design patterns especially. A great place to view all of these is refactoring.guru . I would recommend you set up an automation tool to detect code smells.
Fail fast so you don’t waste time
Use the fail-fast methodology. You should learn rapid development and how to fail fast, so that you don’t commit to a solution only to realize months later that it was wrong in the first place. Use failure testing and stress testing, before committing. I applied the fail-fast methodology on my personal project during the summer to weigh in different options for building an internal documentation tool. It is really helpful when you have to weigh in the pros and cons of different tools, but you can’t be sure what they are until you try them.
Microservices can be as big as you want, but they’re also a journey for your organization
I’ve been reading a lot about this. I’ve watched A LOT of talks on Youtube about the topic. I am also currently developing various microservices. I have to quote Sam Newman, the author of Building Microservices: Designing Fine-Grained Systems, on this and say that people should never start building a system using the microservice architecture, unless there is a valid reason for it.
Also, when you are migrating from a monolith to microservices, it is not just a journey with your code and data, it is your organization that has to change as well. You need teams to handle those services and maintain them. You need to understand the pros and cons of this architecture as it brings complexity into the mix, but also many benefits, two being scalability and faster deployment times.
Many people write heated articles about not buying into the microservice hype. I would say it’s not a hype anymore (it’s approximately 10 years old now), but rather it’s one tool to solve a specific problem. You have to weigh in the good and bad if you want to take that journey, but don’t make decisions based on a feeling. Do the research and experiment.
I also want to add that when I watched presentations given by Uber and other big companies, about their microservice journey, I am glad that we enforced some standards to building external services at work early on. You don’t want to end up in a world of microservices, where each one has their own API design, language, error handling and logging systems. Instead choose the language(s) your company and teams are most comfortable with and select one or two clear ways for logging and error handling. Microservices bring many advantages, but they also bring complexity.
Make sure your integrations are fault tolerant
Learn about the retry pattern with exponential cutoff and circuit breaker pattern. When dealing with integrations you should build your system so that it supports these two.
This way your system is a little bit more fault tolerant. Otherwise you might end up in a situation where an API is unresponsive for hours but you have thousands of error log entries for each time your system tried to connect. You should also have a mechanism in place to notify you when the circuit gets tripped.
Research your topic
Do your research. You can’t just say some thing is not worth it or bad, unless you have actual data or experience to back that argument. That kind of attitude comes from a place of insecurity. I spend a lot of time researching new technologies to see if they’re worth my time, or worth introducing to others. This way I can back some ideas from various angles.
Personal toolbox
Languages, frameworks, design patterns, architecture… they are all just tools in your toolbox. You pick the right tool for the job. There is no one solution for every problem.
However, I would recommend you keep that toolbox at a reasonable size. While it helps to know many frameworks, you often don’t want to use 10 different ones for different solutions, but maybe pick two-three and keep those in there.
As an example I often grab Slim Framework or Laravel for my custom PHP back-end solutions which are pretty much at the opposite sides of the framework weight spectrum. Slim is very lightweight, while Laravel comes with a lot of helpful tools. For any front-end type solution I often go with CRA or Next.js for React, Nuxt.js for Vue.js.
Improve yourself by dissecting a library or framework
Learn how things work under the hood. It’s easy to lull yourself into thinking that all I need is a framework, or a CMS platform, to be a programmer, but you’re not going to be a great programmer unless you can actually develop the things a framework consists of, yourself.
It is also very helpful to look at what others have done so when you have to write some type of framework, it’s not a ball of mud. Frameworks exist so that developers don’t have to spend hundreds of hours doing the same stuff all over again, but if you don’t know what goes into developing a bootstrap sequence for an application to process and route an HTTP request, you might not know what HTTP headers can do, or how middleware actually works.
Open source frameworks are also great because they are developed by a community of developers who most likely have thought of the thousands of things that make a software vulnerable, and taken those into account during development. Like SQL injections, or XSS vulnerabilities.
My recommendation is to grab an existing, popular, framework and take it apart, or write one for yourself, but don’t sell it to a customer because it’s most likely filled with vulnerabilities. Trust me, I speak from experience (although in my defense, I learned those things from a programming book).
Learn from failure
Don’t be discouraged by failure. Learn from it and try again. Otherwise you won’t improve.
Invest some money in literature
Read some of the most recommended tech books out there. Eric Evan’s book titled Domain Driven Design: Tackling Complexity at the Heart of Software really opened my eyes to some new design concepts, both in code and outside of it. What I’ve realized is how much the MVC pattern has taken from this concept and people don’t even realize it. DDD is not some technology or methodology. It is simply a way for you to design your application. A different way of thinking about its structure. I would recommend anyone who works with OOP to read this book.
Natural evolution
Software should evolve naturally and you will eventually begin to see signs for when you might have to take a monolith apart. While this may be completely inaccurate I get the feeling that an evolution of any platform often goes from a monolith, to microservices, to event driven architecture. Each has their pros and cons, but the more data you have to process at high speed, the more you start moving into EDA.
I’ve been learning about EDA and watched many presentations on it, but haven’t had the pleasure of using it in practice. Also note that the term “microservicse” is very subjective. Your service can be as big as you need it to be, but it can be helpful to split and application apart to get the benefits from it while also knowing that it brings a bit more complexity in to the mix.
Security should be a priority
Security shouldn’t, and can’t, be an afterthought. Don’t store what you don’t need. Encrypt sensitive data that you need. Don’t store things like credit card info unless you are a professional at it, but rather pay someone else to do it. Never trust user input.
Learn asynchronous messaging
Use queues. Lately I’ve been doing a lot of development using SQS and SNS, but the idea of queues is something people should learn, when talking about fault tolerant asynchronous messaging. This can sever any hard dependencies between two systems thus making it more fault tolerant.
SCRUM, KANBAN and product ownership
If you work with a team, learn SCRUM and KANBAN, but also learn what product ownership is. Learning what your PO is responsible for will help you. You will also learn what MVP (most viable product) means when working on a timetable and what should be a priority to launch on time.
Don’t burn yourself out
Developer, tech lead and architect are three different jobs with different job descriptions. You can’t do all of them unless you can work 24 hours a day. You propably can’t.
Hardest things in software development
The famous quote “There are only two hard things in Computer Science: cache invalidation and naming things.” is absolutely right.
Document your work
Try not to leave documentation as the last step in the project. Start by scribbling down things you’ve done using bullet points while developing, and finish it once it’s done. This way you don’t have to spend so much time thinking back at what exactly did I do and I need to write down here.
Also, document your API unless you use some tool to do it for you. It sucks having to ask someone or dig into code to figure out what type of payload this API accepts. Also, try to make an API backwards compatible, but don’t be afraid to deprecate versions of it if it comes to that.
Docker helps developers
Docker is pretty great and helps teams work using the same version of the same software on their own machines, locally. Goodbye to days where developers had to install a WAMP server on their computer and someone had a problem with a different version, or everyone developed on the same server.
Web developers should learn Javascript
The Javascript ecosystem is currently on steroids and as a web developer you might wanna jump on that. There are some interesting things being released at a very fast pace which are shaping the front-end world.
I’ve been working with multiple JS frameworks lately and I’m still amazed (and scared) of the things that go into those. You need translators, compilers, bundlers, hundreds of packages making your node_modules folder gigantic while also thinking you’re completely safe in the open source world. While I know how to develop front-end applications using React and Vue, but also back-end apps using Node.js, don’t ask me to explain how you bundle code in JavaScript without just saying “use Webpack”. I have no idea.
Always argue cost
Money drives development. You can’t pay developers with happy thoughts. If you think that you should invest in quality over quantity, always argue cost. I will refer you to read this article from Martin Fowler on the subject. He is absolutely right. Your company will not see any value on developing a completely brand new API using modern tech just because it’s more fun. You have to argue that it will save money in the long run.
Proof of concepts are good
Learn how to build proof of concepts for your ideas to sell them. This will also help other developers pick up the idea.
Always refactor your code
Your software is never done. It should keep evolving and you should keep refactoring it constantly. This is what keeps it alive.