Live data from Hacker News

Enterprise Software Projects Killed the Software Developer

javahippie.net

91–100 of 150 posts

Re: Enterprise Software Projects Killed the Software Developer

#91

Earlier quoted context omitted.

ah, yes and no. You really can't know the internal workings of everything, it's not practical anymore. in other words: you can stand up a web site in less than an hour that will handle enormous loads across the globe, but not if you pause to read all the library code that goes into it. fortunately, humans are pretty good a having faith in things

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 over well. I might have them delete all the pasted code and re-write it with me. If they keep pasting in code they don't understand, I may remove them from my projects.

I'm obviously a lot less strict about understanding libraries we import (although it's still important to develop a strong understanding of what they do, and their limitations, over time). The main difference is that someone else is supporting that code, while we have to support code that we pasted from "somewhere online".

Re: Enterprise Software Projects Killed the Software Developer

#93

Earlier quoted context omitted.

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…

"Reflection, endless hierarchies, complexity on complexity" sounds like the exact opposite of "elegant properly engineered code"

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”.

Re: Enterprise Software Projects Killed the Software Developer

#94

The best enterprice architects I worked with don't know shit. They can plot 3 boxes with 4 arrows and call it a day. They can take credit for working system, it doesn't matter. What really matters is that they don't waste time on useless preplanning, don't give you (as tech lead/senior dev) solutions to implement, but problems to solve. They don't know how to solve integration problems, but they know how to click to…

I agree with this. They know most of the parts, what works smoothly and what needs more love, and they talk to people. Then they can give an informed advice with a few UML diagrams and a few code examples.

Re: Enterprise Software Projects Killed the Software Developer

#95
post #78

this is written like its bad to "hand over code" to others. I don't like it.

Handing over code comes with some very real costs, I think it would be naive to not consider these costs.

That's the main reason for DevOps, as I understand it: one team develops and operates the product. And in the case of DevSecOps, also secures it, rather than a separate team doing so. Some individuals will specialize, but a cross-trained core team ties both (or all three) of these functions together throughout the product's life cycle.

Re: Enterprise Software Projects Killed the Software Developer

#96

Earlier quoted context omitted.

The real problem is that the while the same code might look obvious to John Carmack, it might not look obvious to $outsourced_bodyshop_ressource_0443434. Then you start coding for the lowest common denominator.

What if the NYTimes had journalists that described the news in their specific prose or worse, poetically. Speak plainly, it’s the news, report it as plainly and accurately as possible. Often many people like to attach mathematics and science to Software Engineering to signal elitism, but truthfully this profession is a lot closer to writing. Write clearly, first and foremost, and above all else. $outsourced_bodyshop_…

> What if the NYTimes had journalists that described the news in their specific prose or worse, poetically.

Eh, I think the news landscape would be improved if there was a news source providing it in poetic form. I wouldn't want everyone to do it that way.

Re: Enterprise Software Projects Killed the Software Developer

#97

The best enterprice architects I worked with don't know shit. They can plot 3 boxes with 4 arrows and call it a day. They can take credit for working system, it doesn't matter. What really matters is that they don't waste time on useless preplanning, don't give you (as tech lead/senior dev) solutions to implement, but problems to solve. They don't know how to solve integration problems, but they know how to click to…

Speaking as a — now former — architect, I’d agree! The best use of my time always turned out to be dealing with scope and feature risk, areas of ambiguity, and governance. Part of this is because very few software projects hinge their success on complex and elegant solutions to thorny conceptual problems, but also because competent developers generally don’t need an architect doing much more than sketching out the broad contours for them to get in and design/build the system; what they really need from the architect is client alignment, well-defined feature scope and dependencies, locked down RACIs, realistic team sizes and schedules, and just enough governance to keep everything on track without overmanagement. A successful architect, in other words, is technically-competent enough to figure out what has to go into the solution (which crosses many disciplinary boundaries) and what the overall project size roughly looks like, but the second they try to create detailed technical plans they’re wasting time and money.

Re: Enterprise Software Projects Killed the Software Developer

#98
post #54

There was that interview with Peter Norvig - https://www.youtube.com/watch?v=_VPxEcT_Adc - I believe there he said something roughly like "before programming was about composing algorithms, structures etc. - and engineers used ideas from SICP - now it's about composing 3rd-party libraries and solutions - and engineers don't read manuals, don't worry about how systems work internally etc." Pardon if I stretched the me…

Did Norvig then favor the current Leetcode interview in response?

(Which would then seem like the most dysfunctional example of institutionalized playing to the metrics that our field has ever invented.)

Re: Enterprise Software Projects Killed the Software Developer

#99
post #87
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…

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

#100

Earlier quoted context omitted.

ah, yes and no. You really can't know the internal workings of everything, it's not practical anymore. in other words: you can stand up a web site in less than an hour that will handle enormous loads across the globe, but not if you pause to read all the library code that goes into it. fortunately, humans are pretty good a having faith in things

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…

To be honest, you’re doing the right thing: you should stop and try to figure out where things come from, why they’re there, and what they’re doing. Usually, if you’ve got “magic coupling” from a framework, that’s the part that’s going to bite you or it’ll be where you need to dig in for some critical piece of functionality. It’s not unusual for reflection-, plugin-, or attribute-heavy code (and I’ve abused all those systems heavily in the past, often at the same time) to break in weird and unexpected ways, especially in tandem with other frameworks. Sure, cut-and-paste devs look like they get there faster, but they won’t be able to diagnose and debug regressions, because their knowledge is just another cargo cult.
Post reply on HN