Hello, I am Robin Wenglewski, a Software Engineer from Hamburg.
I build and optimize Web Applications, nowadays often using Ruby on Rails, AngularJS and Docker.
However, technology is exchangeable and should be chosen based on the requirements,
environment it’s going to run in and various other factors.
So instead of asking What technology are you specializing in?, the better question would be
How do you work in your projects and what is important to you?.
So, here is what is important to me:
- proper requirement engineering: getting an early understanding of the goal and features a client has in mind.
- iterative/agile process: Clients often think of the perfect version of the product. Which is good!
However, the pareto principle does also apply to software: You can often go 80% of the way with 20% of the work.
If these 80% provide value and are well rounded, it often makes sense to postpone other, low-value/high-effort features.
- choosing the right technology stack, and utilizing it: It is not always possible to choose the technology stack.
However, smart technology choices and utilizing these technologies can save a lot of work (and thus, money).
For instance, Web Developers often forget how powerful databases are and how much work can be pushed out of your application into the database.
Also, leaving technology out when you don’t need it reduces complexity and with that the amount of work you need to modify software.
- team communication and distributing knowledge:
For me, one of the key benefits of using agile software developement methology is that they encourage team communication.
This is important in so many ways: It distributes knowledge, motivates and let’s the team grow together and see itself as part of a team with a unified goal.
By distributing knowledge risk is also reduced.
- keeping complexity low:
Firstly, it is important to understand that complexity makes changes expensive.
The more complex your software is, the harder it is for a developer to dig in, modify and test changes to it (e.g. new features).
There are a couple of very efficient ways of keeping the code size small:
- split up software into components: By splitting your software up into encapsulated components one can and should keep the complexity of components in check.
These encapsulated compontents can be classes/modules at first, be pushed out into a separate library later, and even be run as separate service.
However, each step also adds complexity, so as always you should start with what you need for sure. And push out code as you go.
- killing features:
This sounds harsh but is important and a thing many people get wrong:
If a feature adds little value but a lot of complexity, it is your responsibility as expert to make the client understand the implications of adding this feature.
- the best code is the one not written:
Each line of code increases complexity and the capacity for bugs which both ends up costing money.
Thank you for coming to this place. I hope you will enjoy the content provided here.