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 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.