9 ms·

I think “industry” strongly implies “corporate world”. However > The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code.

by fuzzy2 2y ago

I think “industry” strongly implies “corporate world”. However > The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code. Guess I’m the corporate world then! Listen here, dear colleagues: Before attempting any finesse, abstraction, wit or beauty, maybe first try to make it work to spec. Because otherwise it is entirely worthless. If you are reasonably good at making it work, you can then make it right and maybe even fast.

halfmatthalfcat 2y ago
I just wanted to make it more explicit since this issue isn't specific to software developers, every career grapples with the "right way" versus the "economically prudent way" in our (US) capitalistic society. That in and of itself isn't bad, take capitalism however you want, but the point is managing expectations to the reality that exists in front of us, not the one you wish it could be.
bdw5204 2y ago
In my experience, most of the corporate world seems to care more about their aesthetic notions of the Platonic ideal of what code should look like than whether or not it works or whether or not it is efficient. Certainly that's my experience from interviews. Maybe the people who care about business value should be the engineering managers not the people who equate their personal aesthetic preferences with the only right way to write code?
- fuzzy2 2y ago
  I’ve had the opportunity to work with lots of mechanical engineering corps to date, and I can confidently tell you: Even if they had some platonic ideal, they would never be able to follow through. The mediocrity of their software development practices is… profound. On all levels of the hierarchy. Sure they care about the ideal of sustainable software development, but they just can’t do it. On the other hand, my employer advertises clean code as a service, and this attracts the kind of developers you describe.
- peddling-brink 2y ago
  Because code is read more often than written? And clean code is easier to read?
  - whstl 2y ago
    > clean code is easier to read What's "clean code"? Capital-C Clean Code? Hell no. This is code that looks clean only on the surface, but in practice it only works on toy projects. Anything big enough is impenetrable for debugging and a performance catastrophe. Lowercase "clean code" from people who heard the above but never even read the book? What's that anyway? Nine out of ten times, this is just developers putting aesthetic preferences in front of correctness, simplicity and performance.
    - amboo7 2y ago
      Wrong. Performance and correctness/cleanness go together. Perhaps you have never tried generating correct code that is ways faster than what you can write by hand.
      - whstl 2y ago
        Once again: what even is “cleanliness”? Are you writing it in lowercase on purpose, or are you unaware of methodologies that share the term? Or are you talking about Uncle Bob’s but refusing to capitalize? “Clean” is a horrible qualifier for code. It is either too subjective/broad, or too loaded.
        amboo7 2y ago
        OK, I realized it was about something else. I don't follow Uncle Bob, and was referring to some people justifying "unclean"/incorrect shortcuts to gain performance.
        whstl 2y ago
        I totally agree with you in that regard, "readable" and "performant" often go hand in hand. My gripe is with the "Clean" adjective, that often indicates code that actually isn't readable and is also low performant.
- deleted 2y ago
  [deleted]
megadog3 2y ago
Counterpoint: The MVP is usually what ends up in production. If your code is a heap of garbage but chocolate-coated on the outside, you're gonna impress management and they'll want to push it live asap. Then the issues start exploding.
- cranberryturkey 2y ago
  yes, a shitty foundation leads to shitty feature implementation. I've seen this everywhere from startups to Fortune 500 companies. Nobody cares about code quality, except maybe the one self-annointed gatekeeper who thinks he's making a difference and shitting on everyone's PRs delaying features. Get rid of that guy he serves no purpose
  - vbezhenar 2y ago
    That guy keeps everything from collapsing.
    - jampekka 2y ago
      Yeah, if the indentation style, variable name capitalization rules, structure of commits, 100% unit test coverage the guy knows is the absolute truth and top priority, a collapse of everything is imminent.
    - sambazi 2y ago
      involved conservationists and curators rarely get the recognition they deserve, but sometimes obstructionists are just that
  - tkdev2 2y ago
    Spoken like a true MBA. Hope I never have to work with you.
  - fireflash38 2y ago
    People don't care about quality in general unless it affects the bottom line. Not just code quality, but product too. Bugs? Who cares unless it costs us money. Security holes? only a problem if they're exploited... And it costs us money.
vegetablepotpie 2y ago
> first try to make it work to spec In my professional experience, the only spec you get is a wishlist, never quantified, always vague. Half the work is figuring out what the customer wants. The only metric that anyone cares about is speed. You need to go fast, but to where? There is no consensus.
- rrr_oh_man 2y ago
  If quick and dirty gets you 10 shots, while slow and beautiful gets you 1, I’d choose quick & dirty any day.
  - rnewme 2y ago
    That's not how you build big important, expensive things, though. It all depends on the context.
    - doomslice 2y ago
      Do you know that the big expensive thing is what your customers actually need? Do you actually know what your customers need? That’s basically the only important context. If you can’t deliver that, it doesn’t matter how well thought through, extensible, or scalable it is.
      - jampekka 2y ago
        Do the customers know what they actually need?
        doomslice 2y ago
        Well if you don’t have a pretty good idea of the problem you’re solving for the customer, you’re much better off trying as many things as you can, quickly and cheaply, to figure out.
    - ericjmorey 2y ago
      It seems that the biggest, most important, and most expensive things are built like that.
tomByrer 2y ago
> you can then make it right and maybe even fast IF there is budget for that very often. Otherwise they'll expect you to move on.
- deleted 2y ago
  [deleted]
withinboredom 2y ago
I live by three steps when writing software: 1. Get it working. 2. Get it working well. 3. Get it working fast. Your last sentence reminded me of that.
- apantel 2y ago
  This is the way to do it. First you want as complete coverage as possible with a unit test showing that the implementation is sound. Then you can try things and refactor for performance, checking as you go that you didn’t break anything.
heresie-dabord 2y ago
There ought to be a good spec (i.e. requirements). But it's hard to motivate people to excel without giving them opportunity to grow their talent. This cartoon remains the best visual representation of an industry that seems incapable of doing requirements, testing, documentation, and security. https://i.kym-cdn.com/photos/images/original/000/475/749/fd8.jpg https://i.kym-cdn.com/photos/images/original/000/475/749/fd8...
tacitusarc 2y ago
Specs are fickle, vague things. Well written code can accommodate the whims of users and execs alike. I also tend to find that folks who write quick and dirty code “to spec” leave it riddled with bugs and unhandled corner cases.
zelphirkalt 2y ago
> If you are reasonably good at making it work, you can then make it right and maybe even fast. Whuahaaaha ... If only that was so easy. Once you get it working, it will in most cases be torn from your hands and you will not get to touch it again any time soon. So what one does to find even a little bit of joy is to try to get some sense into that code right away, because you don't usually get a second chance. If I knew, that at a later point in time I will only have to ask and sure enough I will get the opportunity to make things well-made, then I would be much more willing to not spend any additional time into making things well in the first run. Making things well requires knowledge and craftsmanship, while making things merely as shoddy as possible but according to spec will requite a bunch of interns making a pile of unmaintainable crap. Code only written with the next goal in mind, not looking out for the casualties along the way.
- fuzzy2 2y ago
  I may not have communicated this well enough. I wasn't referring to a multi-step process where I hand over the solution in between. I was referring to getting good at making in work, right and fast in one step (at least as far as the customer is concerned). Many try do it all at once and then end up with… nothing.

by fuzzy2 2y ago

halfmatthalfcat 2y ago

I just wanted to make it more explicit since this issue isn't specific to software developers, every career grapples with the "right way" versus the "economically prudent way" in our (US) capitalistic society. That in and of itself isn't bad, take capitalism however you want, but the point is managing expectations to the reality that exists in front of us, not the one you wish it could be.

bdw5204 2y ago

In my experience, most of the corporate world seems to care more about their aesthetic notions of the Platonic ideal of what code should look like than whether or not it works or whether or not it is efficient. Certainly that's my experience from interviews. Maybe the people who care about business value should be the engineering managers not the people who equate their personal aesthetic preferences with the only right way to write code?

fuzzy2 2y ago
I’ve had the opportunity to work with lots of mechanical engineering corps to date, and I can confidently tell you: Even if they had some platonic ideal, they would never be able to follow through. The mediocrity of their software development practices is… profound. On all levels of the hierarchy. Sure they care about the ideal of sustainable software development, but they just can’t do it. On the other hand, my employer advertises clean code as a service, and this attracts the kind of developers you describe.
peddling-brink 2y ago
Because code is read more often than written? And clean code is easier to read?
- whstl 2y ago
  > clean code is easier to read What's "clean code"? Capital-C Clean Code? Hell no. This is code that looks clean only on the surface, but in practice it only works on toy projects. Anything big enough is impenetrable for debugging and a performance catastrophe. Lowercase "clean code" from people who heard the above but never even read the book? What's that anyway? Nine out of ten times, this is just developers putting aesthetic preferences in front of correctness, simplicity and performance.
  - amboo7 2y ago
    Wrong. Performance and correctness/cleanness go together. Perhaps you have never tried generating correct code that is ways faster than what you can write by hand.
    - whstl 2y ago
      Once again: what even is “cleanliness”? Are you writing it in lowercase on purpose, or are you unaware of methodologies that share the term? Or are you talking about Uncle Bob’s but refusing to capitalize? “Clean” is a horrible qualifier for code. It is either too subjective/broad, or too loaded.
      - amboo7 2y ago
        OK, I realized it was about something else. I don't follow Uncle Bob, and was referring to some people justifying "unclean"/incorrect shortcuts to gain performance.
        whstl 2y ago
        I totally agree with you in that regard, "readable" and "performant" often go hand in hand. My gripe is with the "Clean" adjective, that often indicates code that actually isn't readable and is also low performant.
deleted 2y ago
[deleted]

megadog3 2y ago

Counterpoint: The MVP is usually what ends up in production. If your code is a heap of garbage but chocolate-coated on the outside, you're gonna impress management and they'll want to push it live asap. Then the issues start exploding.

cranberryturkey 2y ago
yes, a shitty foundation leads to shitty feature implementation. I've seen this everywhere from startups to Fortune 500 companies. Nobody cares about code quality, except maybe the one self-annointed gatekeeper who thinks he's making a difference and shitting on everyone's PRs delaying features. Get rid of that guy he serves no purpose
- vbezhenar 2y ago
  That guy keeps everything from collapsing.
  - jampekka 2y ago
    Yeah, if the indentation style, variable name capitalization rules, structure of commits, 100% unit test coverage the guy knows is the absolute truth and top priority, a collapse of everything is imminent.
  - sambazi 2y ago
    involved conservationists and curators rarely get the recognition they deserve, but sometimes obstructionists are just that
- tkdev2 2y ago
  Spoken like a true MBA. Hope I never have to work with you.
- fireflash38 2y ago
  People don't care about quality in general unless it affects the bottom line. Not just code quality, but product too. Bugs? Who cares unless it costs us money. Security holes? only a problem if they're exploited... And it costs us money.

vegetablepotpie 2y ago

> first try to make it work to spec In my professional experience, the only spec you get is a wishlist, never quantified, always vague. Half the work is figuring out what the customer wants. The only metric that anyone cares about is speed. You need to go fast, but to where? There is no consensus.

rrr_oh_man 2y ago
If quick and dirty gets you 10 shots, while slow and beautiful gets you 1, I’d choose quick & dirty any day.
- rnewme 2y ago
  That's not how you build big important, expensive things, though. It all depends on the context.
  - doomslice 2y ago
    Do you know that the big expensive thing is what your customers actually need? Do you actually know what your customers need? That’s basically the only important context. If you can’t deliver that, it doesn’t matter how well thought through, extensible, or scalable it is.
    - jampekka 2y ago
      Do the customers know what they actually need?
      - doomslice 2y ago
        Well if you don’t have a pretty good idea of the problem you’re solving for the customer, you’re much better off trying as many things as you can, quickly and cheaply, to figure out.
  - ericjmorey 2y ago
    It seems that the biggest, most important, and most expensive things are built like that.

tomByrer 2y ago

> you can then make it right and maybe even fast IF there is budget for that very often. Otherwise they'll expect you to move on.

deleted 2y ago
[deleted]

withinboredom 2y ago

I live by three steps when writing software: 1. Get it working. 2. Get it working well. 3. Get it working fast. Your last sentence reminded me of that.

apantel 2y ago
This is the way to do it. First you want as complete coverage as possible with a unit test showing that the implementation is sound. Then you can try things and refactor for performance, checking as you go that you didn’t break anything.

heresie-dabord 2y ago

There ought to be a good spec (i.e. requirements). But it's hard to motivate people to excel without giving them opportunity to grow their talent. This cartoon remains the best visual representation of an industry that seems incapable of doing requirements, testing, documentation, and security. https://i.kym-cdn.com/photos/images/original/000/475/749/fd8.jpg https://i.kym-cdn.com/photos/images/original/000/475/749/fd8...

tacitusarc 2y ago

Specs are fickle, vague things. Well written code can accommodate the whims of users and execs alike. I also tend to find that folks who write quick and dirty code “to spec” leave it riddled with bugs and unhandled corner cases.

zelphirkalt 2y ago

> If you are reasonably good at making it work, you can then make it right and maybe even fast. Whuahaaaha ... If only that was so easy. Once you get it working, it will in most cases be torn from your hands and you will not get to touch it again any time soon. So what one does to find even a little bit of joy is to try to get some sense into that code right away, because you don't usually get a second chance. If I knew, that at a later point in time I will only have to ask and sure enough I will get the opportunity to make things well-made, then I would be much more willing to not spend any additional time into making things well in the first run. Making things well requires knowledge and craftsmanship, while making things merely as shoddy as possible but according to spec will requite a bunch of interns making a pile of unmaintainable crap. Code only written with the next goal in mind, not looking out for the casualties along the way.

fuzzy2 2y ago
I may not have communicated this well enough. I wasn't referring to a multi-step process where I hand over the solution in between. I was referring to getting good at making in work, right and fast in one step (at least as far as the customer is concerned). Many try do it all at once and then end up with… nothing.