5 ms·

Elegant and clever code wont live through a maintenance cycle. I'll take a software developer who writes and structures code so change requests and code are wr

by useful 5y ago

Elegant and clever code wont live through a maintenance cycle. I'll take a software developer who writes and structures code so change requests and code are written in a way that the DSL is the same across the organization. This makes changes easy. Clever people should be writing libraries or doing research. Don't kid yourself, you are either the guy who builds the building and its easy because its greenfield, or you are doing remodeling and the hard part is making the upgrade fit in the building and not look like shit.

javajosh 5y ago
Excellent comment. This is true, and I think golang embodies the idea (or attempts to). Enterprise wants consistency over anything else. That said, there is a type of cleverness that can be brought to bear on Enterprise systems that, for example, take a simple, unidirectional data flow into account - something that is rather abstract, but which can and will thwart lots of complexity down the line.
- IceNotNice 5y ago
  Can you elaborate a bit on the golang part? As someone who dabbled with Go but never found it too alluring when comparing to other options (if I wanted ease-of-use I'd go with Python, if I wanted performance I'd go lower level - C++/Rust), I'm interested what you mean by it. Go did find a footing in the industry and a lot of cloud infrastructure relies on it, I do think it's the most interesting option out of compiled garbage-collecting languages.
  - Aeolun 5y ago
    Go finds a really good position in between. The language itself restricts your ability to get too crazy (with for example types). I hate it, but I can totally see how it would work really well for keeping your architecture simple.
  - ctvo 5y ago
    Go removes non-value added decisions as teams scale: - formatting built in. There’s one way. No preferences needed - language constructs are dead simple. There’s one way to use them, and they’re verbose. No cleverness encouraged - patterns are straight forward Read the standard library code if stuck Every Go project resembles every Go project. It’s great.
- pjmlp 5y ago
  Plenty of languages have traveled that path, COBOL, RPG, xBase, Visual Basic, Delphi, 4GLs, Java, and now Go. The problem is then you get some enterprise architects that go crazy with the design space.
deleted 5y ago
[deleted]
zozbot234 5y ago
The fix is to properly document your code. "Clever" code is an anti-pattern, but there's no need to make your code less elegant or less properly engineered than it otherwise could be. Hacked-together, low quality code is even less maintainable than "overly clever" code, so it's worth trying to avoid that.
- slownews45 5y ago
  Actually - I've found the "elegant properly engineered code" a total NIGHTMARE to deal with. Reflection, endless hierarchies, complexity on complexity. The PHP script kid basically writes a linear program (tons of duplication) with no crazinesses. Yes, it's "low quality", but if you do a few function out refactorings you've got something very easy to work with. I just wish there was a standard template - access check, runtime complexity at code comment at top of function (ie, O(1), O(n), O(n^2)) some reasonable comments, error handling, done. Throw in some unit tests if desired.
  - rightbyte 5y ago
    I full heartely agree. Bonus point for globals you can set checked breakpoints on. Linear long functions are victims of bullying. Sure, it is a balance act, but I take bad linear code over deeply nested code any day. When trying to figure out how code works I can't keep much depth in my head, unless it is some tree walk on a data tree.
    - slownews45 5y ago
      Exactly this. The person who knows all the "engineering" - you have this giant mutating pile of impossible to fellow (but maybe 5% faster) code. The person who just codes enterprise style, long but done and easier to follow and edit.
      - thinkharderdev 5y ago
        I guess it depends on how you define "enterprise" but I always associated that word with unnecessarily bloated code. Or even worse, trying to reduce the amount of code by pushing more and more to ever more complicated declarative configuration files. That is mostly because when I hear "enterprise" I immediately think Java EE, which to me was the exact polar opposite of easy to edit and follow.
TeeMassive 5y ago
For me elegant and clever means that 1) my code won't get in your way and 2) can be thrown away easily. In return I ask a bit more time so I won't self-couple my code with introspection magic or make it undebuggable with weird dynamic design patterns nor will I make wormholes to so that A can communicate with B. Deal?
- useful 5y ago
  deal. code should be written to be easily replaceable, not extendable to me, more often than not, it means simple
feoren 5y ago
I always wonder if people who talk like this have ever actually seen elegant and clever code.
- FranksTV 5y ago
  Everyone has seen elegant and clever code, but it's really not necessary when you're writing a CRUD API.
  - feoren 5y ago
    Then stop writing CRUD APIs; make the compiler do it instead. If you're doing rote, boring, assembly-line programming, then you're doing the compiler's job.
    - smoll 5y ago
      Imagine you’re working at a startup and trying to solve a tough real-world problem by creating software that involves writing some CRUD APIs. You bring on someone to the team who says, “we gotta stop writing these pointless CRUD APIs and write compilers instead.” I’m not trying to be dismissive, but I think this actually well illustrates the central tension between engineers who are more interested in the business problem and ones who are more interested in solving technology problems. I know that when you get to a later stage as a company you need both kinds of engineers, but at an earlier stage company you have to ensure all of your engineers are of the former kind and not the latter kind or you will probably not succeed.
      - Fiahil 5y ago
        I work as a consultant, and we are also looking for talented people interested by solving business problems. We actively avoid the technology-focused kind, because we know they will not be able to adapt to the work we do. To be honest, we write a ton of CRUD apps, but anyone who would come and say "let's write a compiler" is guaranteed to get funny looks. Even if you are extremely talented and can deliver to the same pace as we traditionally do, you will probably fail to consider one or two "little" things that would turn out to be fundamental requirements! Nobody is impressed by half-working cleverly written software.
frebord 5y ago
In my enterprise experience the remodeler usually just ends up bolting more shit onto the existing heap of shit. Dev time ends up taking longer and longer, wasting more and more money. Its funny you mention greenfield being easy in the same sentence - because IMO starting over is often the better option than the shit bolting but no one wants to go down that route because they need it next week. A whole bunch of small shit bolting projects every week instead of sitting down and cleverly engineering better broader solutions.

by useful 5y ago

javajosh 5y ago

Excellent comment. This is true, and I think golang embodies the idea (or attempts to). Enterprise wants consistency over anything else. That said, there is a type of cleverness that can be brought to bear on Enterprise systems that, for example, take a simple, unidirectional data flow into account - something that is rather abstract, but which can and will thwart lots of complexity down the line.

IceNotNice 5y ago
Can you elaborate a bit on the golang part? As someone who dabbled with Go but never found it too alluring when comparing to other options (if I wanted ease-of-use I'd go with Python, if I wanted performance I'd go lower level - C++/Rust), I'm interested what you mean by it. Go did find a footing in the industry and a lot of cloud infrastructure relies on it, I do think it's the most interesting option out of compiled garbage-collecting languages.
- Aeolun 5y ago
  Go finds a really good position in between. The language itself restricts your ability to get too crazy (with for example types). I hate it, but I can totally see how it would work really well for keeping your architecture simple.
- ctvo 5y ago
  Go removes non-value added decisions as teams scale: - formatting built in. There’s one way. No preferences needed - language constructs are dead simple. There’s one way to use them, and they’re verbose. No cleverness encouraged - patterns are straight forward Read the standard library code if stuck Every Go project resembles every Go project. It’s great.
pjmlp 5y ago
Plenty of languages have traveled that path, COBOL, RPG, xBase, Visual Basic, Delphi, 4GLs, Java, and now Go. The problem is then you get some enterprise architects that go crazy with the design space.

deleted 5y ago

[deleted]

zozbot234 5y ago

The fix is to properly document your code. "Clever" code is an anti-pattern, but there's no need to make your code less elegant or less properly engineered than it otherwise could be. Hacked-together, low quality code is even less maintainable than "overly clever" code, so it's worth trying to avoid that.

slownews45 5y ago
Actually - I've found the "elegant properly engineered code" a total NIGHTMARE to deal with. Reflection, endless hierarchies, complexity on complexity. The PHP script kid basically writes a linear program (tons of duplication) with no crazinesses. Yes, it's "low quality", but if you do a few function out refactorings you've got something very easy to work with. I just wish there was a standard template - access check, runtime complexity at code comment at top of function (ie, O(1), O(n), O(n^2)) some reasonable comments, error handling, done. Throw in some unit tests if desired.
- rightbyte 5y ago
  I full heartely agree. Bonus point for globals you can set checked breakpoints on. Linear long functions are victims of bullying. Sure, it is a balance act, but I take bad linear code over deeply nested code any day. When trying to figure out how code works I can't keep much depth in my head, unless it is some tree walk on a data tree.
  - slownews45 5y ago
    Exactly this. The person who knows all the "engineering" - you have this giant mutating pile of impossible to fellow (but maybe 5% faster) code. The person who just codes enterprise style, long but done and easier to follow and edit.
    - thinkharderdev 5y ago
      I guess it depends on how you define "enterprise" but I always associated that word with unnecessarily bloated code. Or even worse, trying to reduce the amount of code by pushing more and more to ever more complicated declarative configuration files. That is mostly because when I hear "enterprise" I immediately think Java EE, which to me was the exact polar opposite of easy to edit and follow.

TeeMassive 5y ago

For me elegant and clever means that 1) my code won't get in your way and 2) can be thrown away easily. In return I ask a bit more time so I won't self-couple my code with introspection magic or make it undebuggable with weird dynamic design patterns nor will I make wormholes to so that A can communicate with B. Deal?

useful 5y ago
deal. code should be written to be easily replaceable, not extendable to me, more often than not, it means simple

feoren 5y ago

I always wonder if people who talk like this have ever actually seen elegant and clever code.

FranksTV 5y ago
Everyone has seen elegant and clever code, but it's really not necessary when you're writing a CRUD API.
- feoren 5y ago
  Then stop writing CRUD APIs; make the compiler do it instead. If you're doing rote, boring, assembly-line programming, then you're doing the compiler's job.
  - smoll 5y ago
    Imagine you’re working at a startup and trying to solve a tough real-world problem by creating software that involves writing some CRUD APIs. You bring on someone to the team who says, “we gotta stop writing these pointless CRUD APIs and write compilers instead.” I’m not trying to be dismissive, but I think this actually well illustrates the central tension between engineers who are more interested in the business problem and ones who are more interested in solving technology problems. I know that when you get to a later stage as a company you need both kinds of engineers, but at an earlier stage company you have to ensure all of your engineers are of the former kind and not the latter kind or you will probably not succeed.
    - Fiahil 5y ago
      I work as a consultant, and we are also looking for talented people interested by solving business problems. We actively avoid the technology-focused kind, because we know they will not be able to adapt to the work we do. To be honest, we write a ton of CRUD apps, but anyone who would come and say "let's write a compiler" is guaranteed to get funny looks. Even if you are extremely talented and can deliver to the same pace as we traditionally do, you will probably fail to consider one or two "little" things that would turn out to be fundamental requirements! Nobody is impressed by half-working cleverly written software.

frebord 5y ago

In my enterprise experience the remodeler usually just ends up bolting more shit onto the existing heap of shit. Dev time ends up taking longer and longer, wasting more and more money. Its funny you mention greenfield being easy in the same sentence - because IMO starting over is often the better option than the shit bolting but no one wants to go down that route because they need it next week. A whole bunch of small shit bolting projects every week instead of sitting down and cleverly engineering better broader solutions.