61–70 of 510 posts
> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
Earlier quoted context omitted.
Damnit me too
Do it, if only to find Clojure.
When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche.
The best way to discover the essence of lisp is to read SICP and learn Scheme.
> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code.
> The best code is no code at all
This can be interpreted as advice to avoid the 'inner-platform effect' anti-pattern. Good advice, but personally I'd rather express it in terms of the inner-platform effect.
> I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so…
Uhm, sweety, just no.
Earlier quoted context omitted.
Someone please translate that to Latin and start plastering that on office walls so people take it more seriously. It’s going to save all of our mental health in the long run.
It's been seven years since I've tried writing any Latin, so you should assume this is butchered. (edit: I think it's less butchered now) codex bonus a discipulo prendatur codex magnus a novo prendatur codex optimus nullus est Part of the problem is I couldn't find any good word for "code". "Codex" sounds cool but may not be the best fit here. EDIT: Forgot a word. Also, I think "prendere" is better for "understood" h…
> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing because it's so terse. It's been a poi…
I think it happens because most measures of code quality are quite fuzzy, but brevity (which is valuable, other things being equal) is relatively objective. "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"
Earlier quoted context omitted.
Someone please translate that to Latin and start plastering that on office walls so people take it more seriously. It’s going to save all of our mental health in the long run.
It's been seven years since I've tried writing any Latin, so you should assume this is butchered. (edit: I think it's less butchered now) codex bonus a discipulo prendatur codex magnus a novo prendatur codex optimus nullus est Part of the problem is I couldn't find any good word for "code". "Codex" sounds cool but may not be the best fit here. EDIT: Forgot a word. Also, I think "prendere" is better for "understood" h…
Earlier quoted context omitted.
That hurt me to read! Have you communicated this to your manager? Might be worthwhile to have a decision "from the top" that is essentially: all logging is good, so long as it doesn't hurt performance or contain PII/PHI.
Logging is like a lamp in the dark, you need it.
1. good logging is the most important part of the app. whatever the app is meant to do is secondary. the app should be a logging app first, and then a backend service to sell widgets second.
2. assume performance requirements for request latency and transactions per second will be at least 3x whatever the product owner tells you at the start of the project and plan accordingly. never trust any suggestion that you can 'ignore performance for now'.
3. the UI may be more important than logging
Earlier quoted context omitted.
Try building something of your own just for fun. See if you see sparks of your old love back.
That's the thing, I've been trying to do that for years now. I've got about a dozen cool ideas that bounce around in my head and a new one every few months or so. I can spend all my non-free time thinking about and designing them in my head, but when it comes time to actually write the code, I just kinda lose all motivation.
I'm considering just hiring people to do the side projects I wish I had the energy to write the tedious code for.
Earlier quoted context omitted.
I wish more managers and business stakeholders investigated this more carefully. Team members of this type add a shadow overhead that impacts velocity dramatically. It’s always visible to average competent devs on the team, but can be invisible to managers who don’t investigate as to why only one person is particularly productive on the team. Most people won’t go to their bosses and say ‘so and so writes overly compl…
I would do this auditing job, no joke. A kind of "code-smell" service, that can yield problematic areas, along with a report of engineers that could use additional guidance/training/reigning-in would be super valuable from a manager's perspective. And because it's a neutral party, they can feel good that there's no politics. One challenging bit about this service would definitely be quantifying improvements. Since th…
If a team was tasked to make a simple landing page for example, and it was oddly hard or time consuming for an average team member, it would be good to dig into why. If the answer is ‘you should see the boilerplate involved, or the deploy process ...’, then you can make a neutral analysis as to the cause.