Clean Code has some truly awful and aged code examples (the prime number generator for instance) and constantly ignores its own advice particularly around avoiding side effects and “single purpose” functions.
Working Effectively with Legacy Code is my go-to junior dev example as I think it’s most important to understand what that means and what it looks like early on!
Assuming you have a job already what skills do you feel are lacking that you could brush up on? IMO it makes little sense to pick up on tech for the sake of trends or popularity unless it helps with either finding a job or being more effective at your current one.
Having said that a great deal of being senior is possessing people skills - communication, being able to give feedback etc. That’s what I would focus on - learning tech should be the east part!
Has anyone actually really noticed the performance of Stack Overflow? It feels like your average website before the JS bloat took over most “forum” style sites.
I wonder if they’ve traded off performance (and by the sounds of it, maintainability) with cost by squeezing all they can out of a minimal amount of hardware.
That's the difference between web development, "web2.0-style", and engineering. A web developer, when experiencing lag, will just add another AWS instance. An engineer will figure out where things are inefficient, and work against that inefficiency. You would be surprised how much of a performance boost you can get just by having good server-side pre-caching.
Also, consider that a lot of the lag you experience in the web today is actually caused client-side by excessive use of JS.
Engineering is a pretty slow-and-steady profession. Best practices, tests, and robustness are part of the point. There's an argument that a good engineer would know when those criteria are satisfied and so be more able to run up to the cusp, but I don't think it is fair to say engineers necessarily (or typically) work against inefficiency. Adding more AWS nodes might be the boring, prudent choice.
Redundancy is a form of inefficiency. Failure paths often introduce inefficiency. Well defined tolerances introduce inefficiency... even though you know those motors could handle a couple extra volts...
I feel like having automated testing though is objectively beneficial. I imagine SO make up for that by having a QA team and spend a heap of time manually testing stuff at the expense of “performance”.
I agree, automated tests of all kinds do have empirical basis every time I’ve seen them used. You can literally see their value by measuring their output. There’s a lot more to the “best practices” around automated testing than just doing it though. And therein lies the rub.
> I imagine SO make up for that by having a QA team
Most places I've ever worked have made automated testing impossible but then gone ahead and made up for it by just never testing anything and then blaming the programmers when bugs show up in production.
That “doubling of cost” thing is utter rubbish. If you produce higher quality code with two people deeply aware of the design and maintenance of a system doesn’t that reduce overall cost? I swear this “doubling cost” is one of those myths perpetuated by Taylorist managers.
I’ve never seen any evidence to suggest pairing is less efficient overall.
> I’ve never seen any evidence to suggest pairing is less efficient overall.
It's not less efficient, but is it really 2x as efficient as having a single senior dev per task, with proper code reviews and tests in place? And it does cost double upfront, you can't avoid that and costs are the limiting factor for many (especially smaller) teams... some of this cost will pay back in terms of bugs being less likely and easier future maintenance and all that, but can you really claim that it will absolutely ALWAYS return the initial investment? To paraphrase on your own words: "I’ve never seen any evidence to suggest it's guaranteed to be that much more efficient".
IME (and I did a lot of pair programming in my career) it depends a lot on the people being paired, how complementary their way of thinking is, and also on the particular task being worked on. It will never produce a worse code than solo programming, that's for sure, so it's great if you can afford it, but if you can't there are other ways around it to come close (code reviews being one), and that was the whole point of my comment.
You argue the pairing is more expensive and then give arguments to the contrary.
To be sure, pairing, in order to be effective, has to be properly planned and executed. It is unlikely to work if you just leave it to your employees to figure out (unless you have some really good folk that can figure it out).
I've seen a few developers see multiple "duplicated" API formats for instance (for different API's) in the same codebase and think those are "duplicated" and then entangle two completely separate API's together. This is worse IMO
There is accidental duplication to beware of. That is when different things looks the same. Then there is real duplication.. Only the later is bad and should be eliminated. Telling the differences is hard
I'd rather look at a simple arithmaticl expression and know immediately what is going on, rather than have to make up a hard to remember name for every small expression that happens to get repeated one or more times in the name of DRY. The same applies to small bits of non-arithmatical code.
> No PR, no code review, no CI. Just a cowboy pushing to the master..
Let's be clear that the dangers here are "no code review" and "no CI".
The others are fine in most circumstances, unless you work on some huge monolithic codebase.
Smaller cross-functional teams should be able to push to master to solve problems then and there without everyone's unanimous approval, and everyone should feel enough safety to be able to make changes to the codebase they share with their team.
The real "root of all evil" is why is someone working against the team from within the team?
Not even at a language level. There are Java developers who only want to work with particular frameworks (Spring) and don't know anything else or want to learn anything else.
