|
Yowzas
Thanks for the kind words on the previous issue's feedback. In reply to one comment, you can't really submit text successfully to the ?q=6 link unless it's a POST with formData. I'm not really sure how you tried to do it, but that's probably why you got an error. Unless you did it through the text input on the website, in which case that's my error.
I saw an article titled "What makes a great software engineer?" (great click-bait title, perfect blend of content summary and sensationalized hook) and the first thing that came to my head was "a little common sense". I'll be honest, I didn't read the paper, but I skimmed the article and from Swizec's, coverage it seems that the majority of the points are related to the more "human" skills associated with software engineering (his coverage could be biased though since he sells workshops tied to those skills). Which makes sense to me, because although you might want to live in an idealistic world where your worth is only measured by the quality of the software you write, the reality of the situation is, it's not. Your worth from a company's perspective (not to be confused with your self-worth) is measured in the amount of money you make (or lose) it. Can higher quality software end up paying off more for a company? Sure, but I present this example.
Engineer A and B are asked to implement a similar feature (independently--imagine two parallel universes). Engineer A is great at writing code, and is able to implement the feature within three days with a few bugs. Overall, a gold star. Engineer B is ok at writing code (it would take them a week to ship with a number of bugs), but can see that the feature is essentially pointless and can back it up with some solid points; they equate it to giving fish hair. Engineer B spend an hour writing up the reasons why they think the feature is going to be a flop and getting some data, then another hour convincing their team lead. The feature is trashed after about two hours of work. In this case, who was the better engineer?
Of course this assumes the lead would listen to the engineer, which hopefully would be the case, but the point I'm making is that part of our responsibility as an engineer is to always balance the cost vs the specifications. High quality code is great, but you know what's better? No code, because that usually means less engineering hours (probably one of the highest costs a company has) to develop and maintain. From this perspective, a little bit of common sense goes a loooooong way.
Those were just some thoughts I had, spurred by that one title. What do you think? Am I bat-shit crazy? Or do you agree? Let me know by replying to the email (I'll know who you are), or submitting via feedback (I'll still find you... jk, I got other stuff to do).
PS. here's the issue.
|
|
|
====================================================================
Published: 12 July 2022
Tags: rust
Chris Hulbert presents a short program for writing generating PNGs in Rust.
|
|
====================================================================
Published: 11 July 2022
Tags: c, encryption
Paul Khuong ponders a method and the performance of encrypting structured internal keys to be random externally.
|
|
====================================================================
Published: 9 July 2022
Tags: hardware, linux
Dmitry Grinberg describes making a business card that runs Linux.
|
|
How did I do?
|
|
1
|
2
|
3
|
4
|
5
|
|
Bad
|
|
|
|
Good
|
|
Want to help and get cool stuff?
Thank you for reading! If you enjoy the newsletter, I would really appreciate you helping me spread the word by forwarding this to your friends and colleagues or sharing it on social media! Get cool stuff for your referrals using your link https://abyteofcoding.com or the buttons below.
If you want to discuss or comment on this issue, head on over to this page at A Byte of Coding. You can also subscribe there if you're new!
Have comments or feedback? Just reply to this email or hit me up on Twitter @AByteOfCoding.
Email landed in your promotions tab? Please move it over to primary so you don't miss the latest issues in the future.
|
|
|
Thanks for your Support!
Thanks to sponsors and supporters like Євген Грицай, Scott Munro, zturak, pek, Emil Hannesbo, Joe Hill, Astrid Sapphire, Gregory Mazzola, moki scott, Michael, Matt Braun, Tim Nash, Christoffer, and Mike Rhodes this newsletter is provided to you for free. If you'd like to also show your support and buy me a monthly meal, you can donate on the Patreon page. It's not necessary, but it lets me know that I'm doing a good job and that you're finding value in the content.
|
|
|
|
|
|
|