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…
Enterprise Software Projects Killed the Software Developer
111–120 of 150 posts
Re: Enterprise Software Projects Killed the Software Developer
#112Earlier 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.
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
#113Earlier 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.
Re: Enterprise Software Projects Killed the Software Developer
#114Earlier 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?
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
Re: Enterprise Software Projects Killed the Software Developer
#116Earlier 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
Re: Enterprise Software Projects Killed the Software Developer
#117"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
#118Earlier 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.
Re: Enterprise Software Projects Killed the Software Developer
#119Earlier 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?
Re: Enterprise Software Projects Killed the Software Developer
#120Elegant 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.
The problem is then you get some enterprise architects that go crazy with the design space.