Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drunk Post: Things I've Learned as a Sr Engineer

old.reddit.com

Post reply on HN
Print view View original

271–280 of 510 posts

Re: Drunk Post: Things I've Learned as a Sr Engineer

#271

Post by anyfoo »

belorn wrote: post #265
anyfoo wrote: post #220

Earlier quoted context omitted.

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…

The kernel itself does not consist of any shell scripts. It may have them for building the kernel, but just like the shell scripts at boot, the problems solved there are much simpler (mostly call compiler and linker on a set of files). So I agree: For simple high level problems a dynamic language is sufficient.

As to your second paragraph, I do agree that C has a vastly insufficient type system from the 70s (even though I think better type systems were already available at the time, but the inventors of C might not have known or cared about that). Rust solves the problem you described, and what you complain about is actually that errors in C tend to be represented not statically enough.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#272

Post by SkyPuncher »

eqmvii wrote: post #5

> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.

I've been fighting this at my company lately. We have a CDF that _clearly_ rewards people who write really advanced Ruby code. We have a lot of working, but not perfectly architected code that people come back through, pull it out into a module, and add a bunch of "included" and meta-programming.

It works. I look at their code and think "that's neat", but you added 0 functionality while making it hard for the lowest half of the engineers to work with. You could have accomplished the same thing with hard-reference to a class.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#273

Post by giantg2 »

OminousWeapons wrote: post #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 suggestio…

I was on call as a new developer on a system. I was not given any procedures or trouble shooting documents. I got a call at 1 am, missed it, and waited one minute to see if there was a message. I did see a voicemail, so I started listening and logging on. Before I could even get halfway through, the person called again (why not leave the voicemail on the final attempt?). So I'm looking for the issue/fix for 5 minutes and they tell me they know who the SME is for the functionality, so they will call them. Why even call me if you're just going to call the SME without giving me time to look at it? I got negative feedback from my manager about the way I handled it. So, I asked how I should have handled it without any training or documentation. They said I should have called the SME. Well, I didn't know who the SME was and there's no documentation or list of what who is the SME for which part of the system, nor was I instructed to immediately call the SME. Again, why not just call the SME first if they knew who it was and the SME didn't create documentation because they are "too busy".

Re: Drunk Post: Things I've Learned as a Sr Engineer

#274

Post by yakshaving_jgt »

odiroot wrote: post #178

> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. The other ones are quite obvious but this is the one that really resonated with me. People, with experience, tend to get more pragmatic and less "academic".

Yeah, the funny thing for me is that I run my business on Haskell exactly for the sake of pragmatism.

The last time I had a job was on a Clojure team, and that team has since abandoned Clojure and some of my former colleagues have come to me and essentially said that they got tired of fighting with runtime errors.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#276

Post by yakshaving_jgt »

EMM_386 wrote: post #148
aszen wrote: post #143

Earlier quoted context omitted.

It seems to like you are refactoring an existing application, I'm personally in the middle of something similar but rather than doing it solo, I'm trying to engage other Dev's, grab their interests by demoing the new architecture and see if I can get a few more hands on this work. I'm doing all of this extra work because I think the best way to create value for a company is to make it easy for other/new developers to…

> It seems to like you are refactoring an existing application, I'm personally in the middle of something similar but rather than doing it solo, I'm trying to engage other Dev's, grab their interests by demoing the new architecture and see if I can get a few more hands on this work. The problem is they literally can't afford it. They looked at "near shoring" companies but they were too expensive. They said we got a q…

Could you expand on why you seem to think (if I’ve interpreted your words correctly), that a project is potentially doomed if the programmers aren’t from your country? That sounds awfully prejudicial to me.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#277

Post by tomtomtom777 »

YeGoblynQueenne wrote: post #261

>> Qualities of a good manager share a lot of qualities of a good engineer. OK, you're drunk.

Really? This one aligns pretty well with what I've learned.

It seems that the entire stack of people in software development is tasked with identifying problems and subdividing them in to smaller problems. This goes for coders structuring lines, architects structuring modules as well as managers structuring teams of architects and coders.

The quality of a software engineer shines through all these layers.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#278

Post by topkai22 »

tsimionescu wrote: post #262
edoceo wrote: post #257

Earlier quoted context omitted.

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: https://xkcd.com/323/

Oh the Ballmer peak definitely exists for POCs, school work and side projects. A couple beers in and then you lose the fear of doing something stupid and start cranking out code.

Not sure about producfion code though, the values are different

Re: Drunk Post: Things I've Learned as a Sr Engineer

#279

Post by topkai22 »

29athrowaway wrote: post #99

> Work from home is the tits. But lack of whiteboarding sucks. Just get yourself a drawing tablet and some whiteboard software like Openboard ( http://openboard.ch/index.en.html ). > Good people write shitty code. Smart people write shitty code. Good coders and good engineers write shitty code. Don't let code quality be a dependent variable on your self worth. That's like saying that eminent book authors write shitty…

Their are authors I generally enjoy that sometimes write terrible pieces. They just tend to do it less often.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#280

Post by jghn »

odiroot wrote: post #178

> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. The other ones are quite obvious but this is the one that really resonated with me. People, with experience, tend to get more pragmatic and less "academic".

As I got older the more I appreciated static typing and expressive type systems. To each their own.
Post reply on HN