I really like debugging and unravelling old fucked up overcomplicated codebases. I feel like it's one of the most long term keeps-on-improving-over-decades skills in programming alongside architecture
I've grown to love code even more later in life, even other people's code.
You know what I hate?
Coding ceremonies (formerly known as "meetings") that produce poorly defined/badly written acceptance criteria for code.
One of my problems is that I've gotten so practiced at reading code that my standards for "this is readable, it doesn't need much commenting" are much lower than those of the other developers I work with. I've had to recalibrate from "Will I be able to understand this six months from now?" to "Will I need to explain this in the review?"
Will I need to explain this in the review?
I like this metric. Going to fork it if you don’t mind.
Be my guest 😊
I feel like if someone is going to blog about my life, I should at least get some credit!
Yeah I gotta report this post for targeted abuse :(
I think this post is too simplistic. Everyone handles good code, but as it works and doesn't cause problems nor raises eyebrows then we just glance over it and take it for granted. Developers spend a disproportional time glancing at bad code because that's where they work on, either fixing bugs or updating it to add features.
Microservices have zero to do with this. Their main features is imposing hard boundaries on independent components that are loosely coupled, and in the process end up with code that is safer and easier to change and even rewrite, simpler to deploy, and more testable. Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.
Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.
Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.
Microservices architecture by itself doesn’t guarantee making anything better.
No one said that microservices architecture was a silver bullet. What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service. Being loosely coupled and having narrower and limited responsibilities naturally lead to simpler projects that are both more accommodating of changes and easier to replace.
Making services smaller doesn’t automatically make easy-to-understand code.
Actually it does. Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code on microservices while their monolith is kept somehow clean, the narrower responsibilities alone result in simpler and more straight forward code implemented with a far smaller codebase. I'm not sure what leads you to assume that more responsibilities, features, and code paths can possibly make code easier to understand.
What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service.
We only get this if we do microservices correctly. That's more or less the whole point of my comment. In many cases, teams rush into splitting their monolith into smaller chunks and call it a day. Without proper monitoring, orchestration/choreography, service boundaries, tooling, etc. microservices will drag a team into territories where they will lose control.
Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code [...]
No, I don't believe that. However, I also don't believe people who write spaghetti code will start writing better code just because now they are writing smaller components. If the team has good coding hygiene, they will produce good code whether it's monolith or microservices. But you have a point. If we are talking about components that are 200LoC, it's more difficult to produce spaghetti (or easier to recover from it). I'm not sure that's the norm, though.
As a final note: I'm not saying microservices are bad, or monolith is better than microservices. I'm just trying to introduce some nuance. I have been part of a microservices transformation and I think it was successful. But we met with many challenges along the way that were not immediately obvious from the beginning. To quote one of the pioneers of microservices architecture:
Don’t think of adopting microservices as flipping a switch; think about it as turning a dial. As you turn that dial, and have more services, you’ll hopefully have more opportunity to get the good stuff out of microservices. But as you turn up that dial, you’ll hit different pain points as you go. (Sam Newman, Monolith To Microservices)
We only get this if we do microservices correctly.
I'm not sure what point you tried to argue then. I mean, is it a valid starting point to presume the hypothetical monolith is the cleanest software project possible but the same people, when peeling stuff off to another service, suddenly unlearn how to write and manage code?
It sounds like you're trying to use very weak strawmen to criticize offloading tasks to separate services.
No, I don’t believe that. However, I also don’t believe people who write spaghetti code will start writing better code just because now they are writing smaller components.
For you to argue that, you first need to start from a point where your hypothetical monolith is a tangled mess of spaghetti code similar to the case you tried to pin on microservices. I'm not sure what would be the point of that.
Nevertheless, if you're arguing over spaghetti code, I'm sure you agree that smaller projects with smaller code bases are easier to untangle than large projects with large code bases. Once you acknowledge that fact, how exactly do you think that limiting the scope of a project wouldn't improve it's maintainability? Are we expected to believe that spaghetti code in large complex projects is as easy to maintain as spaghetti code that is a fraction of a size?
As a final note: I’m not saying microservices are bad, or monolith is better than microservices. I’m just trying to introduce some nuance.
Sorry, I don't think that's remotely relevant to the discussion. This is about monoliths, and peeling other services out of them. In your example, it would be like dialing up from zero to one or two. Even the source in your quote argues against that, and their point is also not about it. Going too far in microservices does not mean "now the monolith calls a lambda".
If the code is written well, it can save a bunch of time and provide a great forum for learning new techniques. Otherwise, if it's written poorly yes I hate it. Like others have state here the title is an over generalization.
Senior engineers have learned through hard-won experience that writing code is the ultimate diminishing return.
I feel seen. That entire section is absolute gold.
Oh man, I hate code reviews with the strength of a thousand suns. In the enterprise world, there are so many constraints and conventions that reading other people code is even more boring than it should be. It's even worse when you LGTM it and your colleagues "accuse" you of not having read it with attention because "I can't believe you don't have any comment on my code".
Well, if you don't even have any comments at all, neither good nor bad, then "LGTM" doesn't ever really translate to "I have read all your code and it's wonderfule/okay enough to pass"...
To me, having worked as a developer for some years now, it means "don't got no time to look into your codes, so here's a stamp of approval to send you along your way, knowing too well that you expected me to look into your code but I didn't"
My point being, if you want to say you read all the code and it's fine, maybe refrain from using "LGTM", which is the universal sign of malicious compliance/not caring.
Great post! We solve far too many problems (many of them are very much in the nice-to-have category) with our systems at my work, the systems get huge and difficult to change or maintain. I'm on a constant campaign to stop people building things we don't need, I'm definitely filling my senior role lol.
I really like debugging and unravelling old fucked up overcomplicated codebases. I feel like it's one of the most long term keeps-on-improving-over-decades skills in programming alongside architecture
I've grown to love code even more later in life, even other people's code.
You know what I hate?
Coding ceremonies (formerly known as "meetings") that produce poorly defined/badly written acceptance criteria for code.
One of my problems is that I've gotten so practiced at reading code that my standards for "this is readable, it doesn't need much commenting" are much lower than those of the other developers I work with. I've had to recalibrate from "Will I be able to understand this six months from now?" to "Will I need to explain this in the review?"
I like this metric. Going to fork it if you don’t mind.
Be my guest 😊
I feel like if someone is going to blog about my life, I should at least get some credit!
Yeah I gotta report this post for targeted abuse :(
I think this post is too simplistic. Everyone handles good code, but as it works and doesn't cause problems nor raises eyebrows then we just glance over it and take it for granted. Developers spend a disproportional time glancing at bad code because that's where they work on, either fixing bugs or updating it to add features.
Microservices have zero to do with this. Their main features is imposing hard boundaries on independent components that are loosely coupled, and in the process end up with code that is safer and easier to change and even rewrite, simpler to deploy, and more testable. Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.
Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.
No one said that microservices architecture was a silver bullet. What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service. Being loosely coupled and having narrower and limited responsibilities naturally lead to simpler projects that are both more accommodating of changes and easier to replace.
Actually it does. Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code on microservices while their monolith is kept somehow clean, the narrower responsibilities alone result in simpler and more straight forward code implemented with a far smaller codebase. I'm not sure what leads you to assume that more responsibilities, features, and code paths can possibly make code easier to understand.
We only get this if we do microservices correctly. That's more or less the whole point of my comment. In many cases, teams rush into splitting their monolith into smaller chunks and call it a day. Without proper monitoring, orchestration/choreography, service boundaries, tooling, etc. microservices will drag a team into territories where they will lose control.
No, I don't believe that. However, I also don't believe people who write spaghetti code will start writing better code just because now they are writing smaller components. If the team has good coding hygiene, they will produce good code whether it's monolith or microservices. But you have a point. If we are talking about components that are 200LoC, it's more difficult to produce spaghetti (or easier to recover from it). I'm not sure that's the norm, though.
As a final note: I'm not saying microservices are bad, or monolith is better than microservices. I'm just trying to introduce some nuance. I have been part of a microservices transformation and I think it was successful. But we met with many challenges along the way that were not immediately obvious from the beginning. To quote one of the pioneers of microservices architecture:
I'm not sure what point you tried to argue then. I mean, is it a valid starting point to presume the hypothetical monolith is the cleanest software project possible but the same people, when peeling stuff off to another service, suddenly unlearn how to write and manage code?
It sounds like you're trying to use very weak strawmen to criticize offloading tasks to separate services.
For you to argue that, you first need to start from a point where your hypothetical monolith is a tangled mess of spaghetti code similar to the case you tried to pin on microservices. I'm not sure what would be the point of that.
Nevertheless, if you're arguing over spaghetti code, I'm sure you agree that smaller projects with smaller code bases are easier to untangle than large projects with large code bases. Once you acknowledge that fact, how exactly do you think that limiting the scope of a project wouldn't improve it's maintainability? Are we expected to believe that spaghetti code in large complex projects is as easy to maintain as spaghetti code that is a fraction of a size?
Sorry, I don't think that's remotely relevant to the discussion. This is about monoliths, and peeling other services out of them. In your example, it would be like dialing up from zero to one or two. Even the source in your quote argues against that, and their point is also not about it. Going too far in microservices does not mean "now the monolith calls a lambda".
If the code is written well, it can save a bunch of time and provide a great forum for learning new techniques. Otherwise, if it's written poorly yes I hate it. Like others have state here the title is an over generalization.
I feel seen. That entire section is absolute gold.
Oh man, I hate code reviews with the strength of a thousand suns. In the enterprise world, there are so many constraints and conventions that reading other people code is even more boring than it should be. It's even worse when you LGTM it and your colleagues "accuse" you of not having read it with attention because "I can't believe you don't have any comment on my code".
Well, if you don't even have any comments at all, neither good nor bad, then "LGTM" doesn't ever really translate to "I have read all your code and it's wonderfule/okay enough to pass"...
To me, having worked as a developer for some years now, it means "don't got no time to look into your codes, so here's a stamp of approval to send you along your way, knowing too well that you expected me to look into your code but I didn't"
My point being, if you want to say you read all the code and it's fine, maybe refrain from using "LGTM", which is the universal sign of malicious compliance/not caring.
Great post! We solve far too many problems (many of them are very much in the nice-to-have category) with our systems at my work, the systems get huge and difficult to change or maintain. I'm on a constant campaign to stop people building things we don't need, I'm definitely filling my senior role lol.