Live data from Hacker News

Enterprise Software Projects Killed the Software Developer

javahippie.net

111–120 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#111
post #91

Earlier quoted context omitted.

As a self taught person who likes to dive deep, I’m starting to realize why I fall behind some dude that watched some YouTube videos, did leetcode and got a job somewhere. I follow a tutorial and if I’m not understanding how the guy got to knowing that the property we should use in that scenario was X, I think I’m not understanding anything and that I won’t be able to build anything, so I halt trying to figure out, b…

> how much of your code do you actually fully understand vs how much is just copied from somewhere? 100% is fully understood. Every single line. A very small percentage is copied from somewhere (usually adapted in some way), but even then: I understand every single line. And I expect the same of everyone on my team. If I'm doing a code review and someone says "I don't know; I found this code online" it does not go ov…

So "your code" only means the stuff you typed in personally? None of the libraries you use, the operating system facilities, the runtimes or compilers, none of that is "yours"? So when it breaks or does something you don't understand, then what? File a bug report, call your work "blocked", and go home for the day?

Re: Enterprise Software Projects Killed the Software Developer

#112
post #29
post #12

Earlier quoted context omitted.

It is ambiguous, "Two plus Three times Five" as a sentence reads and is naturally processed from left to right for a result of " is twenty-five". But to anyone who knows math (precedence), "2 + 3 * 5 = 17"

The order of operations doesn't change because the equation is written out in English versus mathematical notation.

"There is no ambiguity because my context is the only context"

I learned a few years back that lawyers will give you a bunch of "ands" and "ors" in an expression without any concept of precedence. That doesn't necessarily mean left to right works, either.

Re: Enterprise Software Projects Killed the Software Developer

#113
post #87

Earlier quoted context omitted.

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

Everyone has seen elegant and clever code, but it's really not necessary when you're writing a CRUD API.

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.

Re: Enterprise Software Projects Killed the Software Developer

#114
post #91

Earlier quoted context omitted.

> how much of your code do you actually fully understand vs how much is just copied from somewhere? 100% is fully understood. Every single line. A very small percentage is copied from somewhere (usually adapted in some way), but even then: I understand every single line. And I expect the same of everyone on my team. If I'm doing a code review and someone says "I don't know; I found this code online" it does not go ov…

So "your code" only means the stuff you typed in personally? None of the libraries you use, the operating system facilities, the runtimes or compilers, none of that is "yours"? So when it breaks or does something you don't understand, then what? File a bug report, call your work "blocked", and go home for the day?

Yes, "my code" means the code I am responsible for, which includes the rare instances where I copy and paste from the internet. What does "your code" mean to you, if not that?

Correct, the libraries and compilers I use are not "my code". If there is a bug in some library method, I simply don't call that method and do something else instead. This may sometimes mean throwing the library away. Sometimes I will submit a bug report, if the process isn't awful (but it usually is).

I guess I don't understand why any of this is surprising to you?

Re: Enterprise Software Projects Killed the Software Developer

#115

"When Hiro learned how to do this, way back fifteen years ago, a hacker could sit down and write an entire piece of software by himself. Now, that's no longer possible. Software comes out of factories, and hackers are, to a greater or lesser extent, assembly-line workers. Worse yet, they may become managers who never get to write any code themselves." Neal Stephenson, Snow Crash, 1992

When I started reading Snow Crash and he described basically Uber/Doordash etc. in the first 10 pages I nearly fell off my chair. Insane how prescient Stephenson is.

Re: Enterprise Software Projects Killed the Software Developer

#116
post #93

Earlier quoted context omitted.

Well of course, that’s why it was put in quotes. The problem is exactly that. Over and over again you’ll come across architectures that are massively over done but claim to be “elegant and properly engineered”.

yeah - the people actually keeping it simple (not designing for 100 future situations that will never actually show up) don't go on and on about elegrant properly engineered code. In general (exceptions exist of course) the entry level person writes much simpler code, focuses more on what needs to happen now. etc

In my experience it's more likely the entry-level person who will write overly complicated code (or create such systems in general); they haven't yet learned how to identify potential approaches and to choose the most suitable one, and might not appreciate how many of their problems they don't actually need to solve at all.

Re: Enterprise Software Projects Killed the Software Developer

#117
post #115

"When Hiro learned how to do this, way back fifteen years ago, a hacker could sit down and write an entire piece of software by himself. Now, that's no longer possible. Software comes out of factories, and hackers are, to a greater or lesser extent, assembly-line workers. Worse yet, they may become managers who never get to write any code themselves." Neal Stephenson, Snow Crash, 1992

When I started reading Snow Crash and he described basically Uber/Doordash etc. in the first 10 pages I nearly fell off my chair. Insane how prescient Stephenson is.

I really, really hope Stephenson's Fall in Hell isn't prescient when it comes to the rise of Ameristan. That book plus Palahniuk's Adjustment Day are a terrifying glimpse of our boring dystopia morphing into complete dystopia.

Re: Enterprise Software Projects Killed the Software Developer

#118

Earlier quoted context omitted.

You're generally not supposed to think about grammar rules when you read or write a language you know (code or prose)

Your omission of a period is ironic.

You're making my point: the period being there or not does not matter, what matters is that you were able to parse my sentence and understand it without issue, and without needing to think about its grammar, thanks to the pattern-matching abilities of your brain.

Re: Enterprise Software Projects Killed the Software Developer

#119
post #46

Earlier quoted context omitted.

Recently we hired a consultant for our infrastructure. I wrote the code for that infrastructure using best practices I learnt from books, workshops etc. While some ppl from my team have huge issues understanding it, the consultant read it ONCE and knew everything. He was simply a good dev that had a pleasure working for other big shops that wrote the books I read and lead those workshops I attended to. So its like al…

Are you the good guy in this story? Writing code that no one else can understand unless they've read multiple books to push through the complexity? Do you write in Java by chance?

Good guy? Depends how you define that. And it would be challenge to write infra code in java..

Re: Enterprise Software Projects Killed the Software Developer

#120
post #14

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…

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.

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.

Post reply on HN