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: 2, Funny) by Anonymous Coward on Sunday January 22 2023, @08:09PM (1 child)
I 10x programer - npt need writting skils.
(Score: 3, Funny) by DannyB on Sunday January 22 2023, @10:31PM
That timez 1024!
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 4, Interesting) by RamiK on Sunday January 22 2023, @08:31PM (3 children)
I wouldn't quote Stroustrup on this:
( https://www.stroustrup.com/China-interview.pdf [stroustrup.com] )
compiling...
(Score: 4, Insightful) by JoeMerchant on Sunday January 22 2023, @08:50PM (2 children)
When reading point 8 I thought more of how old work needs to be evaluated in the context in which it was created. I have done so many proof of concepts and other low investment quick evaluations that, in retrospect, are sloppy hack jobs, but... What would it have taken to make them "better" by today's criteria? Almost always: a whole lot of what we had very little of at the time, usually time.
🌻🌻 [google.com]
(Score: 3, Insightful) by RamiK on Sunday January 22 2023, @10:23PM (1 child)
C++ is almost 40 years old and Stroustrup is still tinkering with it.
compiling...
(Score: 1, Touché) by Anonymous Coward on Sunday January 22 2023, @11:58PM
Yeah, it's not done yet.
(Score: 5, Insightful) by JoeMerchant on Sunday January 22 2023, @08:43PM (11 children)
>no matter which direction you look, there are wide vistas of knowledge going off in every direction and expanding by the day
Yes, however, so much of this "knowledge" is just repackaging of old concepts. Ask the gcc developers just how different all the languages they support really are. Back in 1983 I learned BASIC, my Fortran 101 class in 1984 was a simplistic joke because the two languages are closer to each other than Spanish and Portuguese...
>The best code is no code, or code you don't have to maintain & Always strive to build a smaller system
So very much this ^^^ . "What did you contribute to this sprint?". "I removed 10k LOC from the project, including dependencies on 4 external libraries ." is so very much more valuable than "I created this huge artifact that leverages 3 other projects in 4 different languages...". Yes, nice, but what requirements are being met by this brittle creation?
>If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. And: Software engineers, like all humans, need to feel ownership.
Oh, man, 5 years ago I proposed a system architecture that put everyone in a single OS working together on a single API, it just required our Microsofties to learn Qt... Non starter. So we have a VM with a separate OS in our system, because Windoze can't support certain system requirements. It's a vast improvement over when we had a DSP doing that work and communicating its results to Windoze for display, but... The regrets when filling out STIG compliance documents are strong in that choice...
>Interviews are almost worthless for telling how good of a team member someone will be
This isn't just true for software, and a great team member in one circumstance can be a horrible one when things change in the same company. So much here is a matter of both luck, and shaping the environment to foster success (when you can.)
🌻🌻 [google.com]
(Score: 3, Interesting) by krishnoid on Sunday January 22 2023, @09:31PM (9 children)
Removing 2k LOC [folklore.org] is noteworthy too.
(Score: 4, Interesting) by JoeMerchant on Sunday January 22 2023, @10:59PM (8 children)
Our high school comp sci class in 1982 had a semester project to write a base conversation application to convert decimal to binary or hex, binary to decimal or hex and hex to binary or decimal. The teacher outlined how to input the from and to bases and branch out to the nine different handler routines, each running about 50 lines of code the way he was showing.
I wasn't in the class, but one day about halfway through the semester when most comp sci students had put a couple weeks of effort in, I floated a 3 line program that would convert any base 2-36 to any base 2-36. The class was not amused, especially when the teacher told them copying my idea wasn't acceptable for credit.
🌻🌻 [google.com]
(Score: 1, Touché) by Anonymous Coward on Monday January 23 2023, @02:16AM (3 children)
Code or it didn't happen!
(Score: 3, Funny) by pTamok on Monday January 23 2023, @09:08AM (1 child)
It was probably three lines of APL [wikipedia.org].
(Score: 2) by JoeMerchant on Monday January 23 2023, @11:04AM
One line was pretty long, after all I was only 14 at the time.... I think the input did the parsing of the number,from,to into one string and two ints for me. One line to define the 36 characters for values, then the third line was compound... I might have used 8 to 10 lines to do it today.
🌻🌻 [google.com]
(Score: 2, Informative) by Anonymous Coward on Monday January 23 2023, @01:03PM
Here are two lines of R code:
It is left as an exercise to the reader to figure out which function does what.
(Score: 2) by ElizabethGreene on Monday January 23 2023, @05:01PM (3 children)
This is interesting to think about. I've never actually written a converter function; I've just used the built-in ones. Do you have more puzzles like this?
(Score: 2) by JoeMerchant on Monday January 23 2023, @06:41PM (2 children)
I don't know about puzzles along the base converter line... one test that I was given in my first job interview, and I subsequently gave to about 100 candidates - 5 of whom actually did it was:
Fill the screen with a sine wave linearly decaying from 90% amplitude to 10%.
Over half would walk away in frustration after 5 minutes or so. Many would beg for time, which we would give in abundance: no limits, but the long-timers never did get it. Amusingly, two over the years did draw the sine wave but willingly ignored the "linear decay" instruction and drew it with an exponential decay instead.
Back in the 80s we did a high school "programming competition" which was full of the usual suspects like: identify Pallindromes, compute and display the Fibonacci sequence, etc.
🌻🌻 [google.com]
(Score: 2) by ElizabethGreene on Monday January 23 2023, @10:25PM (1 child)
That's unfortunate. The hardest part of that is remembering the name of the function that draws a point at an arbitrary location on a canvas. :(
Maybe I'm misunderstanding the linear decay bit. The output should look like a sine wave getting squished into a funnel, right? The amplitude decreases but the wavelength remains the same? The scaling factor for the linear decay is a bit fidgety since it's something like (MaxX-MinX *.8) * (MaxX/x) + 0.1, but still not terrible.
(Score: 2) by JoeMerchant on Monday January 23 2023, @10:35PM
Correct, the tops and bottoms of the sine waves line up linearly, not in an exponential decay.
I forgot one instruction: 10 cycles of a sine wave.
Back in the 1990s we'd just give them a C compiler IDE and turn them loose. By the 2000s I had a little mercy on them and would give them an application already written that drew an empty box, then they had to put the sine wave in that box.
I got all wrapped up like you did about the linear decay factor, but really: just going from 0.9x at the left side of the screen to 0.1x at the right is fine. That bit is a nice test of attention to detail - I think I had one candidate over the years go into that.
🌻🌻 [google.com]
(Score: 3, Insightful) by Beryllium Sphere (r) on Monday January 23 2023, @07:49AM
True, lots of repackaging, but also lots of things that change the way you think about problems. Prolog and Erlang are examples.
(Score: 2, Insightful) by Anonymous Coward on Sunday January 22 2023, @08:56PM (2 children)
Go ahead and innovate all you want. But do so in a new product instead of mucking up something that's already working for people. The magical word here is choice. Then you don't get to deal with the flak. Funny how that works and how none of these guys ever seams to realize it.
(Score: 4, Insightful) by legont on Sunday January 22 2023, @09:31PM
Exactly.
So called innovators can't innovate so what they do - they destroy existing well working products so the place is forced to use their "innovations". The result is mostly crap.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 2) by r_a_trip on Monday January 23 2023, @11:30AM
"Then you don't get to deal with the flak."
True, but then you get to fight an uphill battle against inertia and the stick in the muds will tell you the old system "works just fine". Nevermind they keep it running with ducttape and sacrificing a chicken every now and then.
(Score: 2) by krishnoid on Sunday January 22 2023, @09:12PM (1 child)
Software engineering tends to have the same classes of corner cases [github.com] that legislation does, because you're dealing with human creations rather than natural laws. It's no longer a design or implementation concern at that point, it becomes a policy decision.
(Score: 3, Insightful) by MostCynical on Sunday January 22 2023, @09:40PM
ideal systems manage ALL possible scenarios, even if a default option is "management input required'
once you are dealing with legislative and regulatory compliance in the processes being managed by a system, you come across alot of "what happens in this circumstance?" and the policy people reply "it depends.." and explain the 100 other pieces of information and context needed to make a decision, none of which are collected, stored or in any way available to the system...
Good luck with simplification.
Removal of dependencies on external libraries and APIs maintained 'elsewhere', however, should be rewarded.
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 2) by krishnoid on Sunday January 22 2023, @09:21PM
Well, except for STEM-types. Lots of others want something at least a little innovative, as long as they can't tell it's innovative [ted.com].
(Score: 5, Funny) by Rosco P. Coltrane on Sunday January 22 2023, @09:37PM (3 children)
- I can't wait to spend my days in the middle of the river with a fishing rod
That's it. There's nothing more useful I learned in this business.
(Score: 2) by turgid on Monday January 23 2023, @01:34PM (1 child)
Mind if I join you?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Funny) by kazzie on Monday January 23 2023, @08:58PM
The both of you might find it more enjoyable if you bring a boat as well.
(Score: 5, Insightful) by stormreaver on Monday January 23 2023, @03:18PM
I spent 37 years as a software hobbyist, and 22 of those years as a software professional. They were the best 37 years, and the worst 22 years of my life.
(Score: 5, Interesting) by gznork26 on Monday January 23 2023, @12:03AM
Back in the late 70s, one of my first jobs through a contract house was at a steel mill. Mill management had decided that the direct hire software people only had to write new code. Maintenance would be handled by contractors like me. So one day I got a short request: make it possible for the company auditors to access the company's custom production database using their off-the-shelf application.
The database in question was a hierarchical disk-based creature in which data was stored in trees of an arbitrary number of variable-length nodes. The production software traversed it easily, using flags in node headers to indicate field lengths, repeat counts, and links to child nodes. The auditors' application, however, could only read sequential files. Fortunately, it was smart enough to be able to interpret header info that told it how to read the rest off record.
Once I understood what was possible, I designed a program to create a sequential record from each tree. It was doable. But there was a problem: they insisted that it be written on COBOL. That wasn't a problem. I could redefine the 32K buffer as an array of bytes, and put anything I needed into each byte. Running it, however, would take forever, since I was forcing COBOL to do things it was never in tended to do. A test run, for example, took 10 minutes of mainframe CPU time, which meant I was hogging the mainframe when I ran it.
That one routine that assembled the array was the sticking point. It would be simple to do that in assembler, and as it happened, that exact routine already existed, and was sitting in a drawer. I informed management and asked for a waiver so I could use it, but was denied. So I set about repeatedly running tests, trying tricks to speed it up a bit, which I knew would fail, until they gave in and let me use the routine. With that installed, m the program ran in 10 seconds clock time. An enormous time savings.
So yeah. It's real important to consider maintenance. But also ALL of the users and use cases for the project.
Khipu were Turing complete.
(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.
(Score: 1, Insightful) by Anonymous Coward on Tuesday January 24 2023, @02:12AM
If you are doing lots of completely new stuff where no library exists in any language to help for most of the stuff, then sure it makes sense to pick a language that's great for all the code you have to write.
Similarly I picked perl for an agent because the same perl agent code can be used on multiple platforms without having stuff to be installed (perl is a built-in on many OSes, and you can even turn it into an exe that works on multiple versions of Windows - even those without .Net 3.5, .net 4 etc). So I didn't have to build and maintain multiple versions of the agent for different platforms.
(Score: 2) by turgid on Tuesday January 24 2023, @01:40PM
It doesn't matter how hard you work, what process and quality improvements you make, what projects you rescue, how much you streamline the development process, how much you automate and how much more you get done, the PHBs will have more and they will insist that the most important corners are eventually cut. They will apparently reduce overhead for a few days, maybe even three or four weeks, but then the technical debt will cause it all to fall apart.
Wise engineers will see this coming and prepare to leave. The team will disintegrate. Institutional knowledge will be lost.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].