SoylentNews is people
SoylentNews
An opinion piece but some pretty good advice here. Below is a sub-sample of "20 years of software distilled down into 20 pithy pieces":
1. I still don't know very much
"How can you not know what BGP is?" "You've never heard of Rust?" Most of us have heard these kinds of statements, probably too often. The reason many of us love software is because we are lifelong learners, and in software no matter which direction you look, there are wide vistas of knowledge going off in every direction and expanding by the day. [...] The sooner you realize this, the sooner you can start to shed your imposter syndrome and instead delight in learning from and teaching others.2. The hardest part of software is building the right thing
I know this is cliche at this point, but the reason most software engineers don't believe it is because they think it devalues their work. Personally I think that is nonsense. Instead it highlights the complexity and irrationality of the environments in which we have to work, which compounds our challenges.
[...]
4. The best code is no code, or code you don't have to maintain
[...] Engineering teams are apt to want to reinvent the wheel, when lots of wheels already exist. This is a balancing act, there are lots of reasons to grow your own, but beware of toxic "Not Invented Here" syndrome.
[...]
8. Every system eventually sucks, get over it
Bjarne Stroustrup has a quote that goes "There are only two kinds of languages: the ones people complain about and the ones nobody uses". This can be extended to large systems as well. [...]
12. People don't really want innovation
People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you're doing, and know it will really improve things, then brace yourself for a long battle.
[...]
18. Software engineers, like all humans, need to feel ownership
[...] Give a group of passionate people complete ownership over designing, building, and delivering a piece of software (or anything really) and amazing things will happen.19. Interviews are almost worthless for telling how good of a team member someone will be
[...] No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have "signals" for these things... "if they ask about time off in the first interview then they are never going to be there!" But these are all bullshit. If you're using signals like these you're just guessing and turning away good candidates.20. Always strive to build a smaller system
There are a lot of forces that will push you to build the bigger system up-front. Budget allocation, the inability to decide which features should be cut, the desire to deliver the "best version" of a system. All of these things push us very forcefully towards building too much. You should fight this.[...]
(Score: 5, Insightful) by VLM on Monday January 23 2023, @05:40PM
Number 19 and number 1 go together, some really shitty companies seem to interview on how well you can memorize tricks and algos in Python, regardless of job position, so you can see how their employees end up being a dumpster fire. The real problem WRT #1 is optimistic candidates think "well, I could sure as hell learn to do that in about zero time" because they spent an entire career doing that as management glanced at PC Magazine covers. But interviews are all about minimizing corporate risk and CYA so if the candidate gets fired then no one who said "yes" to the hiring is going out the door with the candidate, so the advice in #19 is pretty bad, a candidate who doesn't know how to shut up about time off is a risk to the hiring committee and the boss.
Regarding number 17 most CS "innovation" amounts to finding old computer science papers from the 70s, noticing that stuff is REALLY fast now, then declaring it the new paradigm. If you think LISP was invented in 2007 by the inventor of Clojure, well... Or that functional programing was invented this century...
Regarding number 20 nothing's worse than that 2am call "uh it ain't working can you instantly fix it" and the problem is something architectural WRT scalability.
I'd throw out some other ideas:
21 Big O notation with a factorial is bad if N might have three digits or more... however if the laws of physics prevent it from ever being more than 3 or whatever, then its fine. Or rephrased I would not sweat shitty algorithms only if the laws of physics or something almost as fixed prevent n from ever being a large number. I once implemented naïve traveling salesperson where n could not by DOT regulation not exceed IIRC "four", which has a long story behind it, but I think we'll be OK.
22 The last 10% of the project always takes 90% of the wall clock time. Honestly its probably worse than that.
23 If your pretend demo is too good, someone in management WILL try to ship it. "Uh, that's not doing database lookups, its literally displaying made up data"
24 The more boring and routine the task, the crazier tools you can safely use, and vice versa. You're implementing what amounts to a todo list, fine, write it in Intercal. Doing some insane automation project that'll touch four departments across the company, then use the same exact tech stack as the last similar project down to library versions if possible, bad time for surprises LOL.
25 The "Joel S Rules Test" or wtf its called exactly from last century are still a valid test. Summarizes to if you work for cowboys you'll eventually end up covered in shit.