Clean Code

What Hacker News says

1. drop_starOct 2026
   Sure, it parses, the same way !isNotEnabled compiles. Doesn't mean I'd want to read it in a PR. You should read the book 'Clean Code' by Uncle Bob if you haven't already.

   The sentence may be valid but it has poor readability. That was my point.

   It's !believes(!isSerious(mentalHealth)) which is both poor code and writing.

   'I think mental health is a serious concern' would be preferred.

   thread
2. jdw64Aug 2026
   I resonate with much of what you have pointed out, but I have a different perspective on certain parts.

   Software consists of various layers, and everyone has their own specific areas of strength. For instance, because I am an application programmer, I often need to write code that prevents the program from halting—aligning with recent programming trends that involve preserving the computation context using monads. In other words, my strengths lie in the overall architecture and interface design. This fundamentally relates to cohesion and coupling. I excel in this area, particularly when dealing with codebases around the 60,000-line mark. This is a realm where books like Clean Code are quite effective (many people dislike it, but it is actually a well-written book). Put differently, I possess the ability to mass-produce software (regardless of absolute quality). Over the course of 7 years, I have built CRUD applications for 43 companies across 16 different domains (ranging from drones and golf simulators to tax SaaS and supermarket POS systems). Therefore, I believe I have at least an average, solid capability in this regard. The primary area where I actually made money was PLC, so while I may not have deep academic expertise, I certainly do not think I lack capability.

   In Korea, the profession known as SI (System Integration) is a field where you enter contracts on a "project" basis. In that environment, I have encountered a wide variety of people. From those experiences, my takeaway is that programming is divided into quite several distinct layers.

   To speak of algorithms first: I learned basic algorithms and fundamental data structures in university. However, in the field where I worked, there were many people who struggled to implement those basic algorithms, yet they still built a large number of applications. Why is that? There was even someone who made an amount of money I could never dream of touching in my lifetime. Why did he make so much money when he didn't even know how to implement basic algorithms?

   The answer is quite simple. It is because the "implementation model" and the "contract and cost model" are different. The contract and cost model is a self-contained body of knowledge. It is the ability to know exactly where to fit a given piece into the puzzle. Implementation is simply the ability to build that piece from scratch. In fact, mostly due to issues like employee turnover and the organization's future maintenance capabilities, many teams (specifically, organizations with lower implementation capabilities) decide on an open-source library and design their architecture based on its API. In these cases, the primary technical challenge becomes how to connect those components based on the performance of that library.

   Yet, people tend to think that only those who can implement from scratch are capable of programming. A person who can take someone else's implementation and piece it together to fulfill their own contract is also a programmer, but people frequently forget this. Depending on which layer you exist in, certain knowledge requires you to implement it yourself, while other knowledge only requires you to understand the contract. I believe this is the core of programming.

   Those on the side that must design and build libraries or frameworks naturally have things they must know about implementation, as they are creating the SDKs. However, I have seen quite a few cases where these very people have no idea how their work is actually utilized in the upper layers. And these types of knowledge are highly fragmented.

   In my case, I am familiar with quite a few paradigms. On my personal homepage wiki, I can differentiate between OOP, DOD (Data-Oriented Design), and others, and in the context of relational databases, I know exactly where the ORM impedance mismatch occurs. However, this is largely an area intertwined with architecture, and its essence is closely linked to David Parnas's theory of information hiding. In other words: to what extent do we hide the internals, and where do we expose them to minimize the contact surface area and ensure a safe connection?

   For example, I can't implement PostgreSQL's B-tree. But I can design a business system using PostgreSQL. I only know the name of TCP congestion control—I don't know how to implement it. But I can build networked applications.

   That's what an 'industry' really is. The ability to trust the contracts of other people's implementations and assemble them. The ability to trust others.

   In that regard, I agree with many of your points. However, I actually believe the software industry needs more of those "average" people. I think the very definition of an "industry" should premise that average people can maintain their livelihoods simply by dedicating themselves to a single specific field. From that perspective, when building one's expertise within this fragmented landscape of knowledge, it is perfectly natural not to know much outside of your own specific layer.

   p.s https://www.makonea.com/en-US/casual/cargo-cult-programming-...

   Show morethread
3. francisofasciiAug 2026
   FWIW, here are the books I bought over that years that people would always say you should read. I would say some of the principles might be out of date, wrong, or overkill, but a good goal is to be at least familiar with them.

   The Pragmatic Programmer, Design Patterns (or some Gang of 4 book), Clean Code, Code Complete

   thread
4. WASDxAug 2026
   Good code is self-explanatory and don't need comments.

   I can really recommend the book Clean Code, here is a summary: https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988c...

   thread
5. PJDKMay 2026
   Speaking as someone who has led teams in small startup .net companies.

   At your level I'd not really be thinking too much about specific C# skills, I'd just expect you to have them. Books wise I'd be looking for texts with a wider application. Pragmatic Programmer, Clean Code, Code Complete. Jeff Atwood maintains a good list https://blog.codinghorror.com/recommended-reading-for-develo.... A lot of those books are quite old now so I'd expect you to have some opinions on what part is timeless wisdom and what part is out of date. You should also be looking to the books that are outside your direct area of responsibility, about design, user testing, management. Even if that's not your bread and butter, knowledge of those areas will be increasingly valuable to you.

   I'd also expect you to have experience with and opinions on the use of AI in coding and in products.

   With 7 years experience I would be looking to you to be guiding people on the team and and taking on projects and decisions.

   Finally on much more practical note, we found at our size (15 person company with a dev team of 5) that we would basically never get job applications from adverts so half the time we wouldn't even put one up. You'd be wise to talk to some recruiters. It's also very much in their interest to get you hired so they can give you much more specific advice.

   Show morethread
6. globular-toastSep 2025
   "Model" is an overloaded term. In Domain-Driven Design there is the domain model at the centre of the application. One model consisting of many classes (entities and value objects), functions etc.

   Then there's the ORM thing, particularly active record ORMs, where "a model" means a database table. And things like serialisation libraries (e.g. Pydantic) where "a model" is one type.

   Something that changed how I thought of it was in Robert Martin's Clean Code where the says the whole MVC lives in the outer layers of the application. So basically, "model" is context specific. It depends what part of your application you're talking about. MVC is about building GUIs, that's it. An application usually consists of a lot more.

   Show morethread