>> Qualities of a good manager share a lot of qualities of a good engineer.
OK, you're drunk.
Drunk Post: Things I've Learned as a Sr Engineer
261–270 of 510 posts
Re: Drunk Post: Things I've Learned as a Sr Engineer
#262Earlier quoted context omitted.
Reminds me of Hemingway's "Write drunk, edit sober."
Not for code tho. I've never seen booze help make good code
There was an old xkcd about this, though I will admit I have never experienced this:
Re: Drunk Post: Things I've Learned as a Sr Engineer
#263> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.) I agree but think it is more than just _documentation_: effectively communicating ideas through text was one o…
I've seen lack-of-documentation worn as a badge of honor. "I'm moving so fast, I can't waste my time on documentation. That's the next guys problem." And management is usually/always ok with this short-term optimization.
We had a guy that always opened PRs with no description. Guy always said “read the code”. Manager wouldn’t do shit and he kept doing it until we all just stopped reviewing his code and then he couldn’t merge.
Like dude, tell us why we should read the code in the first place.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#264"Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology."
It sounds great because it is great. I don't make that much and I work on boring systems.
I guess those numbers also explain why the author can recommend maxing out the 401k. People supporting a family on less than $100k don't have $19.5k per year to put into it.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#265Earlier quoted context omitted.
I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and…
EDIT: Reading again, I think you are comparing interpreted with compiled languages, not so much static with dynamic type systems. Seg faults are a prime argument for static typing. The more static and stricter the type system, the less things like seg faults can even happen. Compare Rust to C (both are static, but one more than the other), and at the extreme end handwritten assembly ( extremely dynamic). Those are la…
As an kernel developer, would you want to take some of the many shell scripts that the kernel has and rewrite them in C?
Different tools for different purpose. Unless there ecosystem was really designed for it, I would not write a driver in a dynamic language. At the same time, I would prefer not to write all the bootstrap scripts during booting in C. If all I am doing is calling other programs, I use shell. If all I am doing is calling a bunch of low level system calls in a restricted environment I would use C. If I am doing a bunch of string editing, process flow management, data compiling with some calls to external programs, I would use a dynamic langue like Python.
I want add a personal opinion in regard to C. Every function gives out an return code which is a kind of "type" that does not get enforced by the compiler. The return code is defined by the manual page and it is up to the programmer to catch it and react correctly to it. If the wrong code occur and the program explode during runtime its the fault of the programmer for not write a program that manage the return code. I would claim that the wast majority of crashes that occur in programs written in C is because programmers failed to realize the full list of possible return codes and what they mean. Here I do prefer dynamic languages because they usually do not leave it up to the manual to defined what return code -42 means compared to -41, and debugging errors when the errors themselves have class names and inheritance tend to be a bit easier in my experience.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#266Why does he hate pandas?
Re: Drunk Post: Things I've Learned as a Sr Engineer
#267> The older I get, the more I appreciate dynamic languages. Exactly the opposite for me. I just can't stand hovering a variable or a parameter and not getting its exact type, or typing "." after a variable and not having my editor gives me all the available methods on that variable, or running my code just to discover that it instantly crashes because I made a typo or forgot an argument or passed the wrong argument o…
Depends on how expressive you are being.
There are some problems where you don't want any barriers to getting your idea out of your head.
No rules are best for new exploratory code.
Types and structure are good for existing code.
I wrote Ada years ago when it was newish, and it was hard.
But working on existing Ada code is wonderful.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#268> If people are trying to assign blame to a bug or outage, it's time to move on.
This is one of my favorite excerpts. I once worked in a lab where we would have frequent catastrophic failures because there was never any disaster planning or contingency management plan. I personally triaged 3 such incidents alone or with people who happened to be there when the problem arose and attempted to disseminate some suggestions for how to prevent similar problems in the future. No one was interested. People were primarily interested in tearing my head off because I hadn't handled the problem the way they would have done it (of course, they were out drinking beers or sleeping while I was dealing with the issue at 12 AM or on a weekend).
After the third time I said fuck it, the next time there is an issue I am going to insure my own projects are safe and then I'm going home and turning my phone off. Let someone else deal with it. That is the not the culture you want to be promoting.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#269Earlier quoted context omitted.
I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and…
EDIT: Reading again, I think you are comparing interpreted with compiled languages, not so much static with dynamic type systems. Seg faults are a prime argument for static typing. The more static and stricter the type system, the less things like seg faults can even happen. Compare Rust to C (both are static, but one more than the other), and at the extreme end handwritten assembly ( extremely dynamic). Those are la…
Comment about seg faults. You can with a little upfront work trap them and pull enough information off the stack to know where that happened.
I find that 90% of the time I can figure it out via inspection of the offending code.
Opinion: The class of bugs that cause seg faults in some languages cause run time errors in other languages.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#270Earlier quoted context omitted.
It all depends on your use case. If your input is bound to a small N, I’ll take the simplest to understand implementation regardless of algorithmic complexity. Future you and other people will thank you later.
If small-bound is 50, yes. Otherwise, be careful; future people will not thank you for that timebomb.
If you're really cool, you make it throw an error if n > 50 along with a comment explaining why, or at the very least leave a comment saying "this is not the optimal algorithm and will break if N gets much bigger than 50".