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) 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]