Live data from Hacker News

Nobody cares about your clean code

felipecsl.com

141–150 of 177 posts

Re: Nobody cares about your clean code

#141
post #97

Earlier quoted context omitted.

Not a good idea. That is not a good idea of you let anybody in a management role see your prototype. It will be the product. They will start selling it straight away. If there are any problems, you, my dear young and foolish friend, will be the one at fault. It is your wonderful self that will staying up all hours desperately trying to fix the problems. Otherwise peachy!

I do not understand how you cannot easily "spin" a prototype that the company wants to sell into a good thing. When you write that awesome prototype, your management will be thinking about rewarding you, not blaming you. They will listen to your concerns. So, you can say that it's not ready. You can mention that you alone are not enough to fix the bugs that come up in greenfield code right away. You can even ask for…

Spin? My leaky, fragile, missing important parts, flaky prototype has been sold for a lot of money and is now supporting business decisions.... Spin? Like tail spin....

When the prototype explodes in exactly the way I expect it to management are not going to reward me...

I said it is not ready. Several times. To the point where management stopped taking my calls.....

Manageable amount of bugs? There is a problem of definition here.

The cost of developing a prototype that demonstrates the interesting and cool parts of the project - whilst leaving the tricky bits for implementation is my job. So I gota ask: that cost is too high for whom?

It has been fun....

Re: Nobody cares about your clean code

#142
post #43

John F. Woods (who I actually knew IRL briefly - nicer guy than his online reputation suggests) said it best. "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." I'll just add that the psychopath in question might be your own future self.

Oh boy... I believe I'm this kind of psycho, when I see my name in a git blame after tracing a bug that I didn't foresee... I feel awful, disgusted, then I fix it and think "You sure are dumbass, now try to be a lesser one".

this is always fun with git-bisect because if you can reliably reproduce the bug it will always leads you exactly to the commit that caused the problem. Nothing worse than tracing for a half hour and... it spits out your name.

Re: Nobody cares about your clean code

#143

"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what…

When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.

I have done quite a lot of prototypes and while the initial ones were throw away code, I quickly realized that I can re-use a lot of code in future prototypes. Especially code that involves building user management and database access. Also realized it is frustrating to write repeating code. So I quickly started making code slightly more readable and reusable.

It's not the holy grail of software development but it ain't shitty code either. Also I tend to use only one web framework - FastAPI, one database - mostly Redis or MySQL and one front end React. Saves a ton of time as I can reuse a most parts of the code.

I do think there is a lot of merit in using something like GAE. Saves a boat load of time but comes at a cost and I am willing to bear the cost to save time.

Re: Nobody cares about your clean code

#144

If you are a single developer , sure, knock yourself out, and stick everything in a single file. If you actually ever plan on ever having other developers contribute to and maintain your code, or god forbid multiple teams of developers, you better have things structured in a way that they can understand.

I had to dig into a niche TLS library a few months ago and was aghast at the 50000 line source files with massive God functions all over the place. I don't know how it ever was allowed to get that fubared or how they maintain it all.

SSL/TLS are godawful messes of standards, they are insanely complex to implement which is part of why they have had so many bugs turn up in recent years.

Re: Nobody cares about your clean code

#145
post #84

Earlier quoted context omitted.

Is this stealth promotion for Go?

Go does not have a REPL with interactive introspection and fiddling capabilities. Such a thing is key for prototyping.

go run main.go works just fine and is blazing fast compared to many compiled langs.

There's also scripted go, which may solve some of what you need.

Print debugging works for 99% of introspection needs. Most times go does just as advertised, though learn of common pitfalls to avoid.

Haskell has REPL and dynamic introspection, but everything takes 4-20 longer times. Maybe it's faster/better with massive practice.

Honestly, most codebases just sucks, including my own, unless you redo alot and put deliberate efforts over time. Which is irrelevant to sales (point in link). Alot of value in battle-tested code turns invisible too, locking knowledge away in obscurity. Go at least is pretty readable and mostly explicit.

Re: Nobody cares about your clean code

#146
post #137
post #116

Earlier quoted context omitted.

Yes, but this often occurs a few months or years into production, way too late to throw it away. I've never written a prototype, nor seen one written, in actual businesses. I've never had an employer with the patience to let me play with a prototype either.

If it happens years into production, especially after the load has increased or requirements have changed, it is a legitimate version 2 :)

I've seen rewrites introducing massive bughunts and upsetting customers without improving too much. I've also seen customers expecting and even relying on old bugs for comfort.

Rewrite is always a business decision and need legitimate reasons. You rarely have those reasons, knowledge and time between projects.

Re: Nobody cares about your clean code

#147

Earlier quoted context omitted.

When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.

When I was working on this https://codaris.github.io/UnderDeskBike/ I honestly didn't know if what I wanted to do was even possible at many layers. I didn't know how to do Bluetooth. I knew nothing. It's not worth doing things "the right way" right off the bat because you might not know what that is. My first version was literally a linear file of statements and console output. Once I got something working and unders…

This is really how all new code is birthed. You start build something from no prior knowledge and few assumptions. It gives maximum agility and freedom to pursue multiple paths initially.

Re: Nobody cares about your clean code

#148
post #5

Earlier quoted context omitted.

yea, but isn't the obvious logical conclusion that clean code allows you to more easily and more quickly do things that the customers do want? this is like telling a mechanic that people don't want them to maintain their cars, they just want a reliable car that won't leave them stranded also, why does a php and jquery app mean it isn't clean? the better takeaway is that customers don't care about your stack

It's not quite that simple: it is not unusual for an overall-clean solution in response to new requirements to require refactoring the existing codebase, even if that is a clean and minimal solution for the requirements up to that point. Even if you had anticipated that these additional requirements were likely, preparing in advance for their possibility would often mean over-engineering for the initial requirements,…

The problem with over-engineering is also that it makes other refactoring harder at later stages, or just discourages change. Some degree of shittiness actually improves agility, and encourages change.

Re: Nobody cares about your clean code

#149
post #145
post #84

Earlier quoted context omitted.

Go does not have a REPL with interactive introspection and fiddling capabilities. Such a thing is key for prototyping.

go run main.go works just fine and is blazing fast compared to many compiled langs. There's also scripted go, which may solve some of what you need. Print debugging works for 99% of introspection needs. Most times go does just as advertised, though learn of common pitfalls to avoid. Haskell has REPL and dynamic introspection, but everything takes 4-20 longer times. Maybe it's faster/better with massive practice. Hone…

REPL with hot-loading is better than print debugging, especially if you work with graphics, but also if you do weird stuff in the memory space than make strings unreadable for human beings.

That said, gdb is probably in the same space as git is: hard to fully use, but the best in its own space.

Re: Nobody cares about your clean code

#150
post #149
post #145

Earlier quoted context omitted.

go run main.go works just fine and is blazing fast compared to many compiled langs. There's also scripted go, which may solve some of what you need. Print debugging works for 99% of introspection needs. Most times go does just as advertised, though learn of common pitfalls to avoid. Haskell has REPL and dynamic introspection, but everything takes 4-20 longer times. Maybe it's faster/better with massive practice. Hone…

REPL with hot-loading is better than print debugging, especially if you work with graphics, but also if you do weird stuff in the memory space than make strings unreadable for human beings. That said, gdb is probably in the same space as git is: hard to fully use, but the best in its own space.

I envy your use cases, but it's 25 years since I used debuggers. I just didn't have the use case.

With Haskell being a tough nut, maybe it could help though. So may as well try it.

I found git trivial to start using immediately, and almost possible to understand from first principles (ie. almost like versioned subdirs improved). It's a bit more involved, but with right online content, one starts to catch on (leaving magical thinking).

Post reply on HN