171–180 of 224 posts
Earlier quoted context omitted.
There are only two hard things in Computer Science: cache invalidation and to know when not to use abstraction.
But what about naming things
Earlier quoted context omitted.
The student said to the teacher: "This fence is in the way and obstructing the flow, it should be removed" The teacher said to the student: "If you can tell my why someone made the fence in the first place, I will allow you to remove it." Note that this has nothing to do with "code ownership". If you worked for me and randomly changed code that you did not like, I would fire you.
> If you worked for me and randomly changed code that you did not like, I would fire you. From one extreme to the other? People make mistakes, educate them instead of brutally punishing them. Talk it through - isn't this exactly the mistake that was made by the developer (they didn't talk to their peers)? If they do not respond to feedback, that can eventually lead to a firing.
However, if the behavior persisted then yes, I would fire them.
If anyone sees code that they hate they are free to submit an issue and I will be happy to review it and prioritize it with the other work to be done.
If they hate code that smells so much that they want to volunteer their time to refactor it, then they can participate in code reviews for me instead.
"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…
> While undeniably true, this feels completely orthogonal to the question of clean code. I think this mentality and the Clean Code Movement (with capital Cs) actually have a lot in common. Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things. Anyone who does things differently is doing things the wrong way. There is a subset of programmers who are attracted to…
I liken the CC movement to religion - it has good intentions, but when taken too far you end up with a holier-than-thou attitude.
This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
Most engineers seem to have the wrong takeaway from this post. Every abstraction goes from right to wrong eventually. The answer is not to not abstract, the answer is to ruthlessly tear down abstractions when they go from right to wrong, which people seem to have trouble doing.
I think the other major problem with abstractions is that they have a cost and no one seems to like to discuss that. Even the right abstraction has a cost.
Earlier quoted context omitted.
> While undeniably true, this feels completely orthogonal to the question of clean code. I think this mentality and the Clean Code Movement (with capital Cs) actually have a lot in common. Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things. Anyone who does things differently is doing things the wrong way. There is a subset of programmers who are attracted to…
> Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things Well if this is the case then they certainly didn't get it from the Clean Code book itself. The books very explicitly makes the point that there's no one right way and that the guidelines in the book won't apply to every situation.
> Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well. [emphasis in original]
Earlier quoted context omitted.
HN has a lot of people who seem to benefit from these types of “common sense” articles that bury the lede, judging by the fact they appear on the front page so frequently. (Putting common sense in scare quotes to acknowledge that this is new information to some, no matter how obvious to others)
Is it really the case? Could it maybe be that these clickbeity titles are upvoted and comment on more, regardless of the questionable added value to the community "burried" deep inside?
Earlier quoted context omitted.
Two reasons, one technical, one social. Firstly, the original developer probably spent more hours thinking over and working on that bit of code than you have -- so maybe they had a good reason for doing it the way they did. You won't know unless you ask them. Secondly, I think it's a fairly natural and common human behaviour that when you spend a lot of time working on or making something that you feel some degree of…
I've heard this many times... 'take ownership of your code' ... but the problem is the vast majority of devs work for corporations who own the code, and unless you're a shareholder that code certainly isn't yours, it's corporate property, that's the deal in most employment scenarios. Realistically, people doing such work care very little about writing 'great code' because they know they have no real 'ownership'. Ther…
The code I write is corporately owned in the legal sense but I still feel some attachment to it and care about good workmanship.
"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…
WHY do we write clean code?
Because the value of software is its ability to CHANGE. Otherwise we would stick with fixed circuits. Best practices and clean code don't exist in a vacuum and they are not floating abstractions that developers should throw around as if everyone is on the same page with respects to what they mean.
They are a set of quality standards that allow for the rapid development, adaptability and ease of maintenance as a codebase evolves over time.
Clean code does not exist to slow or hinder development, or to handicap junior developers. It exists to maintain a team's velocity as the scope and scale of the project increases. Clean code is one of the crucial tools in the toolbox for avoiding death march projects. It it is not the only tool: an efficient management process, feedback loop, QA cycle, deployment process etc. are all critical as well. It is a team effort and code quality is the part that rests directly on the shoulders of the developers.
The one and only part of the blog/article that I agree with is the part about refactoring without making it a teaching moment for the dev who wrote it. That part implies they weren't doing code reviews, another crucial element in the quality control of the product being developed.
It blows my mind that these conversations are so often misunderstood. Us old timey senior devs have a professional obligation to make sure that the younger generation understands these concepts. Why do we see so many trendy medium articles and blog posts that seem to want to throw decades of hard learned lessons out the window? I blame the older generation for failing the younger ones. This stuff is not self-evident and has to be taught.
This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
1. Write _anything_ that works. Dependencies, code quality don't matter. Code is idiosyncratic but can be understood by a reviewer.
2. Apply abstractions _everywhere_. Re-implement data structures and algorithms (maybe unknowingly). Code is now very hard to understand.
3. Figure out one is completely unable to update or even maintain code written 6 months ago. Rewritten code suddenly becomes clearer, one begins to think about programming as an craft and not just hacking things on a keyboard until you get the desired result. Dependencies, judicious comments, code quality and a sane terseness become important. The journey starts here.
Personally, step 1 was very short as I learned to program on the job. I was responsible for code, and so I needed to get it together quick. A language like Python makes 2 very easy, and 3 came very quickly too since, as I mentioned, I was responsible for the code (one man team).
I have met people who work at large institutions who are stuck at 1. Others with degrees in CS who are stuck at 2. Some just "get it" and go straight to 3. But typically, the real journey starts when you need to go on with work but your prior self is preventing you from being efficient. You need to get rid of that prior self's work to move on.