101–110 of 150 posts
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.
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…
I am a self taught developer, and I did one a couple months back and it really opened my eyes to a lot of stuff.
Look for the one on Coursera, it's free and really good. Just actually do the assignments. It's a lot of work but really worth it.
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…
That sounds very true. I am always joking that I could probably "architect" our whole Fortune 500 company in a few days.
In sense an architect should be mainly coordinator and communicator. Find alignment and make sure everybody does their part. Detect problems and get everybody back on the same page.
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.
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…
Earlier quoted context omitted.
"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”.
etc
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 br…
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.
Earlier quoted context omitted.
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.
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 compile…
- 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.
Earlier quoted context omitted.
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.
> The fix is to properly document your code. I disagree that is the fix. I've seen horrible code that has extremely extensive documentation, and nice code with minimal documentation. I know which I would rather work with. Documentation has its place, particularly for high level concepts and shared data and interfaces, and tricky, exceptional, or surprising things in the code itself. But it's a poor crutch for bad des…
> I have never seen SCRUM or any agile approach working in a project setup ever. I am biased, though, because a company that truly lives agile values won’t do software development in a project setup When I first read the Agile Manifesto - around '99, I think - it seemed clear to me that this was a great leap forward in software design, but that it was clearly implied that this couldn't be used in a "fixed deadline" e…