> My point is that I rarely don't regret (for my careers sake) jumping in and delivering (obvious to me heh heh) value right away because I see the code I see where it ought to be and the new boss is really eager to see somethin, but I'm steamrolling toes and throwing elbows in eyes that I was entirely unaware of. I guarantee the people you will work with do not see you as a senior for some time, any misstep is a case against your status,
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.
Well a lot of this depends on context. I've worked at a place where (for reasons beyond my knowledge), there was a pre-existing false conception of my experience and level. In that situation, it was important to disprove that false perception early. Especially in a competitive environment, establishing your cred is important.
In a more functional and team oriented environment, your advice is absolutely critical.
Regardless, it's the personal relationships that are primary here. And there can be some nuance in how to handle those. Jumping in and alienating people would not be a wise choice :)
Yeah... one might use Sonic to load a csv and generate sounds based on your data, that might then be used as static assets in their app.
I recently helped a tutor using BespokeSynth to create audio explainers, wiring together frequencies and interactive oscillators and waveform viewers to explain resonant frequencies (or something, I didn't completely get it)
Just because someone is confident about their own weird interpretation of something on the Internet does not make it true.
I (and lot of people I know) use elipsis in writing all the time... usually to indicate a pause or change of direction from the previous thought. If I am in a hurry to get technical details down in text and off to some team, worrying about 100% correct proper writing style is time and luxury that I almost NEVER have.
And besides, unless you work in a law office or something, email is NOT a formal communications method. Grammar and spelling should be within acceptable limits but not a deal-breaker. Otherwise you'd be skating near the principle of judging a book by its cover which would be very un-woke.
> Just because someone is confident about their own weird interpretation of something on the Internet does not make it true.
Agreed. Though in the case of “cool…” there is precedent. For example, John Oliver says it sarcastically¹ with some regularity. Well, he can’t say the ellipsis, but it’s how I’d have written it.
Either way, I’m agreeing with you. People also think that putting a period at the end of a text message is rude², which is bonkers to me³. Soon we won’t be able to use any punctuation without it being considered dismissive⁴.
> People also think that putting a period at the end of a text message is rude
Yes, this is essentially the kind of thing that I was thinking of. It's nutty.
I submit that anyone who assuming malice on the part of the sender without ANY direct evidence to support it likely has some trust issues to work out with their therapist. I started out my adult life being deeply distrustful of basically everyone and it took a LONG time to learn that (lacking direct evidence) assuming the best in people's intentions makes you a lot happier and gets you a lot farther in life.
I'm also reminded of the saying, "offense is taken, not given."
A good rulem of thumb I've found is, if your comment doesn't bring any value and could be taken as rude or flippant, then there's no need to post it. IMO this "Cool..." fits that description pretty well. Nothing to do with "woke" etc. Just doesn't bring any value.
From my perspective simple boolean means a single known value stored in one variable. I suspect the underlying code performs a number of calculations for each one of the flow chart "booleans". Of course, maybe that points to a design flaw and there should be a single policy instance that aggregates all of the variables into one place.
If AI makes junior developers "better" than senior developers then what stops senior developers from adopting the tools and becoming once again better than the juniors?
It's basically true for every profession. We even have a word for it, we call it wise. They built up an experience that they rely on during decision making and produce good results. Changing that is hard.
> Coverage as a whole I think is useful only if you have an engineering organization that doesn't see the point in tests - which is going to be its own uphill battle.
I think coverage stats are always useful as they help find the edge cases that people forgot to test. A common culprit I've seen is error handling code where a bunch of tests target the happy path, but nothing tests the error logging when something breaks.
I think it's a more important feature than just a cosmetic color. Imagine if you bought a truck to haul cargo, but were then told it can only transport one type of cargo at a time. That would suck.
> it's connected to wifi (and it just happily connects even if it's been off for a month or two), and all devices can just connect to it and print. Never need to reconnect or do anything with it. It's a printer that prints. I love it.
Wifi is the only "innovation" that I cared about when buying a new printer. My old Brother just had USB, which was fine for 12 years. But my newer (10 years old) Brother has wifi and printing from the couch is great!
WiFi is a nice feature, but instead of buying a new printer, I setup a CUPS server on old raspberry pis and turned both my and my parents’ printers into WiFi capable ones. Now our 5+ and 15+ year old printers are just as good as any new ones today.
There are 12 year olds working in Cobalt mines, I wonder if Musk is going to send his children to work in those. Some people have to live on the street, maybe we all should, otherwise it's "messed up".
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.