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

461–470 of 510 posts

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

#461

Post by themulticaster »

NortySpock wrote: post #12
vageli wrote: post #3

> 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…

The first thing to learn is that there are four types of documentation: learning-oriented tutorials goal-oriented how-to guides understanding-oriented explanations or discussions information-oriented reference material https://www.writethedocs.org/videos/eu/2017/the-four-kinds-o...

In contrast to the current sibling replies, I think this is a very fitting categorization of documentation. Off the top of my head, I can think of several examples where one type of documentation is excellent but others are very lacking, for example:

* Rust Library Documentation: Most libraries have complete and up-to-date reference documentation, but are lacking even basic introductions (tutorials/guides) on how to use the library. This is totally just my personal experience so maybe I've been looking at the wrong crates, but with most of the crates I spend several minutes looking trough all the modules in order to find that all the juicy functions are hidden in the Connection struct, or something similar.

* Linux Kernel Documentation: The Linux kernel has excellent in-depth explanations on several high-level concepts, but on the other hand a little more systematic reference documentation on the supporting library code would help a lot.

* While I can't think of a good example right now, a lot of projects have a few basic getting-started tutorials but don't explain advanced concepts or high-level design at all, leaving you to wade through the sources yourself in order to understand how to actually use them.

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

#462

Post by sethammons »

convolvatron wrote: post #285
MikeDelta wrote: post #114

Earlier quoted context omitted.

They should try programming on an airplane or without internet connection. For some the productivity drops to zero without stack overflow.

i grew up a long time before stack overflow. actually used man pages and read books. there is just _no way_ to program in Rust or Go without access to a search engine and the package libraries.

You can spin up godoc locally and access it locally fyi. Wont help pull in a new package. And you can always drill down into the stdlib implementation right from your editor if you have jump to declaration. I wrote a custom consensus protocol implementation in Go on a flight for work sans wifi.

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

#463

Post by lostcolony »

giantg2 wrote: post #455
lostcolony wrote: post #417

Earlier quoted context omitted.

So while some employers require X years of (specific tech), many, MANY don't. They expect X years of development. Broadly. Can program and are AWS certified? Start looking. And if there's nothing in your area, look remote. You can hit that salary and solid benefits (no pension) in most metro areas (I hit it with 5 years dev experience, and only a bachelor's, back in 2015 in Atlanta, for a non-tech company). You are a…

Glassdoor's market rate/comp tool says I'm actually making market rate for the area. One major downside to switching is that it involves more time to come up to speed, like putting in extra hours. I can't really commit to that because I have to watch my kid as soon as i log off of work (after 8 hours).

Glassdoor's tool is not very useful I've found. It only even somewhat works for salary, since it doesn't require bonus or equity incentives (which is sufficient in some markets, not others), leading to deflation of total comp. It also doesn't track things like overall years of experience, or how long a person has been in a position. All of those matter, as internal raises have tended not to match the market's increase; the lower end of the market is filled with people who have been in their position a long time, the upper end of the market is people who have job hopped recently, style of thing.

The past couple of jobs I've had I came in at the upper end of Glassdoor's reported salary, for the specific company even, even when I had relatively few years in the role, and without negotiation on my part. And Glassdoor didn't at all represent bonus and equity properly. Levels.fyi did a much better job of it (but has fewer data points for non-tech companies).

I have never worked extra hours to come up to speed (and in general haven't put in extra hours, though I've sometimes had to work weird schedules due to working with people across timezones), and have pretty consistently been a high performer.

I'd still recommend just doing some searching. Worst case, you validate that your current comp is the best you can get. Mediocre case, you find you could get paid better, but not doing anything you feel comfortable taking. Best case, you find something that is interesting and exciting and will pay you better.

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

#464

Post by lostcolony »

ctvo wrote: post #424
lostcolony wrote: post #412

Earlier quoted context omitted.

"Everyone focuses" = nothing gets done. I've been at places like that, where a post-mortem happens, a course of action is decided on...and then no one owns actually carrying out that course of action. You could argue that "It should be assigned" - yeah, it should. But assigning it implies either "here is the team that is responsible for it", i.e., this is the team responsible and they need to be told to fix their shi…

The people most capable of taking the action items are assigned it. This could be expertise, resourcing, proximity, etc.. In an open discussion of the root cause, many times the issue is across multiple services / organizations within a company. You’d assign tasks appropriately across teams as needed. The key is to find and create actionables to address the root cause, not to punish / blame individuals.

"The people most capable of taking the action items are assigned it. This could be expertise, resourcing, proximity, etc."

Expertise and proximity are facets of responsibility (well, technically they are facets of knowledge, but ideally knowledge, empowerment, and responsibility are aligned, else things ALSO won't get done). Resourcing is a red herring; I've seen things get assigned to teams based on "they have the capacity", without it being an area whose domain they're familiar with (i.e., they don't work in that area, and ergo are not responsible for the outcome) - those things rarely get done, and never get done well.

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

#465

Post by lanstin »

derekja wrote: post #122
MikeDelta wrote: post #105

Earlier quoted context omitted.

Indeed, and during rewriting they realize why the original code was made that way and how it solves the problem more efficiently than their rewrite.

if they get to that point I’d say it was worth their time!

Yeah this is the best argument for rewrites. Rewrite what your group no longer understands.

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

#466

Post by lanstin »

jlos wrote: post #112
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.

As a junior, the best I've seen is surfacing the complexity appropriately: 1) Readable Interfaces usable by juniors when parts of the code will be used by lots of devs and will almost certainly change 2) Higher complexity behind the interface for parts of the code that change less often and require more skilled engineers

And complexity needed to make a simple interface is the most forgivable complexity. Simple API, worth some cost to get there.

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

#467

Post by giantg2 »

lostcolony wrote: post #463
giantg2 wrote: post #455

Earlier quoted context omitted.

Glassdoor's market rate/comp tool says I'm actually making market rate for the area. One major downside to switching is that it involves more time to come up to speed, like putting in extra hours. I can't really commit to that because I have to watch my kid as soon as i log off of work (after 8 hours).

Glassdoor's tool is not very useful I've found. It only even somewhat works for salary, since it doesn't require bonus or equity incentives (which is sufficient in some markets, not others), leading to deflation of total comp. It also doesn't track things like overall years of experience, or how long a person has been in a position. All of those matter, as internal raises have tended not to match the market's increas…

"I have never worked extra hours to come up to speed (and in general haven't put in extra hours"

What kind of job do you have? I thought extra hours were normal in tech?

I have looked around. This area (Philly region) seems to be pretty terrible for tech jobs. There are some higher paying ones, but they tend to be niche.

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

#468

Post by lanstin »

the_only_law wrote: post #35
ilrwbwrkhv wrote: post #27

Earlier quoted context omitted.

Try building something of your own just for fun. See if you see sparks of your old love back.

That's the thing, I've been trying to do that for years now. I've got about a dozen cool ideas that bounce around in my head and a new one every few months or so. I can spend all my non-free time thinking about and designing them in my head, but when it comes time to actually write the code, I just kinda lose all motivation.

Just do it at work. All this side project stuff is ok but a lot more stress (I.e. deep thought killer) than just being a bad attitude employee and doing something awesome because you think it will be good. Don’t spend too long on it. If your learn something, you win. If it is useful to other people at your job, double win. The worst type of employee or a software project is the well-intentioned sincerely obedient one. That is how mega disasters happen in software. Despite sprint scheduling stuff, you can take a week and play with some new stuff. You will look bad in Standup for a while, but cost of victory is looking bad for a little in some bogus unimportant context. When you finish the new thing, write a story for it and then sell the hell out of it to the other people.

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

#469

Post by lanstin »

dclowd9901 wrote: post #106
ilrwbwrkhv wrote: post #13

> When I first started, I was enamored with technology and programming and computer science. I'm over it. This is the saddest. One more soul taken by the shrinking of the hacker culture.

The other day, I started playing this game called TIS-100. The game simulates something like assembly programming and I had so much fun with it. Then I realized it’s been nearly half a year that I’ve actually written proper code for something (rather than a GitHub workflow script or account provision mechanism for testing framework) and built something that I was actually proud of. The love and passion are still ther…

Part of the problem is, to borrow an analogy, the frame has gotten really big and the space for the painting is smaller. We recently finished a two or four sprint to ... deploy yellow world. It has bitbucket pieces, Jenkins pieces, EKS terraform, et.c etc., we were all super happy that it worked, but it doesn’t do as much as you can do with twenty minutes in basic in a 1990 PC. And most of the people that wired all this stuff together can’t even write code to draw parabolas or calculate or whatever. It used to be I would develop for a few months then spend a week or two getting stuff in production, for new projects, or few days adding features/bug fixing form existing code, then get it shipped in a few days. There was thorough testing thru code all along, and evil network layers, and so on., and most of the head space was in the code. Now it seems like teams end up spending months trying to get a docker image with all their dependencies and yaml files and so on. And the code is just taking some SQL that ran in a database and running it on some new cloud platform that is still solving acid problems Oracle mastered twenty years ago. Half the code is just orchestration run this hello world Spark job that moves data from here to there. It is cobol level Scala.

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

#470

Post by lanstin »

sanderjd wrote: post #459
gentleman11 wrote: post #327

Earlier quoted context omitted.

My c++ code has so many someptr!= null checks it’s not even funny. But js has those same checks. What languages don’t?

Also, maybe it's pedantic, but leaving out null checks in js will not result in a seg fault , it will result in an exception.

And that is different how, as far as a sign the programmer didn’t think the code thru and maybe you can get around some security controls?
Post reply on HN