Hacker News new | past | comments | ask | show | jobs | submit login
Drunk Post: Things I've Learned as a Sr Engineer (reddit.com)
1086 points by tosh 14 days ago | hide | past | favorite | 495 comments



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


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".


How was the interview process before you got hired on? Any warning signs that seem obvious now in retrospect?


The hiring process for the company wasn't special. Of course half the stuff they claimed in the interview changed later (was hired as a Java dev but was assigned to Filenet, they said rhet dont outsource or layoff but have started doing both).

This was an internal transfer. There were definitely warning signs in that interview. I was desperate because they were outsourcing my job in an obscure tech (Filenet) and we were expecting a kid.

The hiring manager said something to the effect of, "I was surprised anyone internal even applied to this job".

'Warning flag' doesn't do this justice. I have no idea what to call it, but desperation required I ignore it.


The issues in your earlier post point to a problem with the company as a whole. It is surprising that the issue is with a specific role.


What do you mean exactly? There are tons of problems with the company. Stay long enough at any large company and I'm sure there are plenty. The issues can change dramatically from department to department.


The lack of documentation/procedure, and the process issues with others contacting you needlessly instead of the SME. They just seem like structural issues that would not be specific to one team.


Oh. Other departments are better in those areas. We had troubleshooting and recovery procedures in the previous team.


> SME didn't create documentation because they are "too busy".

Because they keep getting shoulder tapped to put out fires. Because they’re the only one who knows the system. Because there is no documentation…


Basically. Except there were 3 other tech leads in that area. They didn't know that specific piece of functionality, but they could be given the new work to take stuff off that team's plate to make time for documentation. The leadership in that area didnt really care about anything other than delivering fast. Testing? Eh... Security issues? They're not that big of a deal - do them on an above and beyond basis (contrary to enterprise policy). On call documentation? Not even going to try to create it. I mean really, all you have to do is create a knowledge document out of the SNOW incident ticket. Then the next time it happens there will be a link to the steps taken. But no.

Quoting what a HN user said in another post a few months back "if a person can break a system, the system was broken to start with".


Eh, that's a nice thing to say, but it only makes sense at certain scales, and no matter what, there's always a person that can break it.

If any random person can break it, it's already broken.

If any employee can break it, it's probably broken (there are very small scales where even this doesn't apply. Ever worked for a company with less than ten people? There's probably something any employee can break).

If any employee that's an engineer, sysadmin or developer can break it, well now you're at least reducing the problem to a more specific set of people.

If only the people on a specific team responsible for a system can affect the system, now you've reached fairly good point, where there's separation of concerns and you're mitigating the potential problems.

If only a single person can break the system, you've gone to far. That effectively means only a single person can fix or work on the system too, and congratulations, you've engineered yourself into a bus-factor of one. Turn right around and go back to making sure a team can work on this.

Finally, realize that sometimes the thing only one team can break is an underlying dependency for many other things, and they may inadvertently affect those. You can't really engineer yourself out of that problem without making every team and service a silo that going from top to bottom. Got a shared VM infrastuture, whether in house or in the cloud? The people that administer that can cause you problems. Don't ever believe they can't. Your office IT personnel? Yep, they can cause you problems too.

Some problems you fix by making it so they can't happen. Other problems you fix by making it hard to happen and putting provisions in place that mitigate the problems if they do.


There are lots of places where we require that no single person can break the system at least in a certain way.

For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code.

Often there are other control planes that don't have the same requirement, but I think the idea that there must always be one person who can break the system isn't clearly true.


> For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code.

Assuming code reviews are 100% effective at catching issues, particularly issues that cross multiple projects. Yes.


I'm making an (admittedly subtle) distinction here between complex mistakes, where something was missed, and simple mistakes/bad actors where someone used a privilege in a manner they shouldn't have.

LGTM ensures that, for example, a single individual can't push a code change that drops the database. On the other hand, that same individual might be able to turn of the database in the AWS console.


> LGTM ensures that, for example, a single individual can't push a code change that drops the database.

Personally, I've seen LGTM let slip complex bugs in accounting code (admittedly, not great code) that went on to irreversibly corrupt hundreds of millions of accounting records.

Yes, it will catch "DROP DATABASE", but when it's still letting through major bugs that similarly require a full restore from backup... It seems functionally equivalent?

Given:

> There are lots of places where we require that no single person can break the system at least in a certain way.

I don't think code reviews are a solution. I mean, they're one of the better solutions I can think of, but they're not actually a solution.


> For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code.

There's always someone with rights to push code manually, or tell the system to push an older version of code which won't work anymore. Someone needs to install and administer the system that pushes the code, and even if they don't have direct access to push the code to where it eventually goes, someone's access credentials (or someone that controls the system that has access credentials) has access somewhere along the way.

But who controls that the code system is up and available even allow checkins? Can one person break that? What about who controls the power state of the systems the code gets checked in on? Is that also ensured not to be a single person? What about office access? What about the power main at your building? Is it really impossible for one person to cause problems there?

It might sound like I'm changing the goal posts, but that's sort of my point, these are all dependencies on each other. It's impossible to actually make it so one person can't cause any problems, because you can't eliminate all dependencies, and you can even accurately know what they all are. What you can do is focus on the likely ones, put whatever in place you can that's sane, but focus all the crazy effort you would have to do to track down the diminishing returns of trying to make failure impossible and start spending that time and effort on making recovery quick and easy.

Unfortunately, some work that goes into attempting to make sure any one person can't cause a problem might actually make that harder. Requiring someone to sign off on a commit to go live is great at 2 PM Tuesday, but not so great when it's required to fix something at 2 AM Sunday. This is the tightrope that needs to be walked, and also while even if you don't necessarily know about it, there probably is someone that has access to break something all by themselves, because they're who is called in to makes sure it can be fixed when the shit hits the fan and all those roadblocks to prevent problems need to be bypassed so the current problem can actually be fixed.

Any system that doesn't have some people like that at various levels persists in that state only until they have a problem and in the incident assessment someone needs to answer why a 5 minute fix took hours and the answer includes a lot of "we needed umpteen different people and only a fraction were available immediately".

Even at Google (which I see you work at from your profile), my guess is that people in the SRE stack can cause a very bad day for most apps. My guess is that even if the party line is that no one person can screw anything up, you probably don't have to ask to many SREs there before someone notes that it's more of an aspiration than a reality.

Sorry if that's a bit rambly. I know you weren't specifically countering what I was saying. I've just had a lot of years of sysadmin experience where it's pretty easy to see the gaps on a lot of these solutions where the face presented looks pretty secure.


What systems are you working on? Many are held together by ritual, and deviating from the ritual causes outages. They’re very fragile in some form (deployment, change, infrastructure, dependencies, etc.). They won’t break if you follow the happy path, but to say they’re so robust that an active attempt at breaking won’t bring them down is ... naive? Not sure if that’s the word I’m looking for.

I say this as someone who’s worked at large tech companies that are “internet scale”.


Maybe. I've seen the opposite, where no one takes responsibility for anything, and it's also bad. In fact, the situation you describe could also be a lack of anyone else taking responsibility for disaster planning and etc.

I think what is needed is a culture of -ownership-. That's basically people saying "I'm responsible". Not one where everyone tries to avoid responsibility, and not one where peopel point fingers.


Why does someone need to take responsibility when you can have a culture of blameless postmortems where everyone focuses on making sure what ever happened never happens again instead? In blameless postmortem culture, everyone is responsible by default


"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 shit (which very much sounds like blame), OR it implies "here is the team that I am entrusting to fix it DESPITE their obviously not being responsible for it", which is just as bad, since it implies that the team that 'is' responsible for it is incompetent.

The only healthy option is that the 'responsible' team stands up to say "hey, that's ours; we'll fix it", and the only way they'll do that is if you have a culture of safety and ownership.

Also, one thing to make clear - ownership = responsible = blame. They're all words for the same thing, just different implications. You can't have someone 'own' something without making them responsible, and apt to be blamed if you don't ensure the culture is one that does not attach blame. That's really what I was getting at; of course you shouldn't blame. But, you can't also avoid ownership. But ownership implies you know WHO to blame, and so blame comes very easily. And it's very easy to mistake pointing out responsibility/ownership for something as blame; I have had multiple managers tell me "it's not us vs them" when I've raised up the fact that I'm unable to deliver to deadlines because I have been unable to get anything from product.


But ownership of a fix is not blame for an incident. Those aren't the same.

You don't say "this incident was your teams fault". You say "your team is responsible for ensuring that this incident can't happen again".


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.


The blameless postmortem an "legal fiction" that don't really mean that blame cannot be assigned just that blame cannot result in punishment or loss of face/standing.

At the end of they day you are going to have someone stand up and say: yep we should have planned for this, and we will correct this in x, y, z, ways.


What does it mean to be responsible? Just to say it? Responsibility should be accompanied with fines corresponding to the damage or something like it. Otherwise those are just words. I'm responsible, but I'm not getting any fines if something goes wrong, so whatever, but I'm responsible. Fire me if you want, I'll find new work in a few days, but I was responsible.

It's business owner who's responsible, because ultimately he's getting all the expenses when critical event happens, client leaves, client sues the company, and so on. Other people are not really responsible, they just pretend to be.


So I've actually written about this in the past, but, responsibility is -actually effecting the entity-.

That is, "you're responsible for this" - if they do it, and it succeeds, what happens? If they don't do it, and it fails, what happens? If the answer is "nothing" in either of those cases, they're not actually responsible. If the result is too detached, they're also not actually responsible (i.e., if I decide not to do one of the ten tasks assigned to me, and I don't hear about it until review time, if at all, then I was never responsible).

Responsibility is innately tied with knowledge and empowerment, but without going on at length, and to just give an example - if I'm the one woken up by the pagerduty alarm when something breaks, I am responsible for that something, because its success or failure directly affects me. If, however, there is a separate ops team that has to deal with it, and I can slumber peacefully, responsibility has been diluted; you won't get as good a result.


Just speaking for me, but if my employer would start issuing fines... lets just say i would starting to run...


So how did it play out? Please, do not let me hanging here.


Honestly, I don't know; I unknowingly followed the author's advice. About half a year after the last incident, a friend who I went to school with called me up and offered me a job at his fledgling biotech. I accepted and never looked back.


This, and the current “sober” posts on r/ExperiencedDevs, makes me think of Herodotus describing the way the Persians made important decisions - once sober, once drunk, and if the drunk and sober decisions were the same they knew it was a good one.


Reminds me of Hemingway's "Write drunk, edit sober."


Not for code tho. I've never seen booze help make good code


Alcohol really does not help me with code either (except maybe a relaxing beer), but Marijuhana works(occasionally). But you really, really need to do the sober clean up part. Otherwise it becomes a mess.


I cannot work while stoned - velocity drops to a crawl, and any complexity becomes overwhelming. And dealing with colleagues becomes much more difficult.

I can code with a few drinks in me; in fact the activity of coding seems to reduce the amount I drink (I'm a functioning alcoholic).

It's decades since I drank during working hours. In my early career in the City, it was the custom to drink at lunchtime. Those days are passed.


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


I'll admit to banging out v0.0.0 code with a buzz. Mostly it's comments and shit-code as documentation. Sober eyes and test cases before production.

So maybe write drunk, edit sober does work


Write drunk, test sober?


Sort of a guilty secret but I used to save POC work for right after a company talk or party and a few beers. I could spew out a few hundred lines of code that was a bit messy but was got the job done. I’d go over it and clean it all up the next morning. Almost always an incredibly productive exercise for me but ymmv.


In college, being drunk once helped me figure out an issue with some PostScript code I was writing.


I find “write sober, review drunk” to be much better advice.



Write code drunk, write tests sober?


The Persians also have an expression for "drunkenness and truthfulness", masti o rasti. مستی و راستی


There’s also Pliny the Elder, in vino veritas (in wine there's truth, for the non-classicists in the audience).


I think Tacitus had a similar anecdote about the Germans.

(Even without getting drunk, I've always found it useful to consider a hard decision once analytically and once intuitively, and if I don't agree with myself, think about it some more.)


https://en.wikipedia.org/wiki/In_vino_veritas Is the phrase. Useful if you want to appear cultured at a company party.


This is right for the drunken dev thoughts, but not for the Herodotus example. "In vino veritas" - in wine there is truth - means that people expose their true thoughts when they're drunk rather than the filtered version they might present when sober, but the story of the Persians is more about the fact that there's value in considering both drunk and sober reactions, particularly when they tally.


In Hebrew we have "נכנס יין - יצא סוד", loosely translates to "Wine entered - secret came out".


or "children and drunks tell the truth"


> 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 of the most underrated skills in software engineering. I say "was" as I think there is much more focus on it now with remote work and video call fatigue becoming the norm for many.


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


I would suggest you avoid thinking in too general of terms like this. There are dozens of kinds of docs. It's better to think about the document's specific purpose, audience, what you need to convey, what the audience wants to know, and how they want to absorb it. Then write, then read it as that intended audience, see if that person can make sense of it, and if it provides enough information. If you can't put yourself in their shoes, have the audience proofread it.

Two important lessons I learned:

1. Formatting and direct communication is very useful. It can make the difference between someone stopping and noticing critical information, or skipping it because they're lazy readers.

2. You probably don't know the correct way to convey information, and the audience probably doesn't know how to tell you how to convey it either. You need to listen for when the docs fail: when somebody says they read the docs but still don't know something or don't do something right. That means your doc has a "bug" in how it gets through to the reader. Experiment, change things around, add/remove information, etc until the bug is gone.


Agree with the sibling comment, but a starting point is also just to write docs for your future self, which is usually going to be type 3 or 4. Most of us who have been programming for a few years have had the experience of being mystified by something we ourselves wrote in the past, so it eventually becomes fairly straightforward to predict what kinds of things future-me will need a hand in piecing back together.

And it turns out those kinds of docs are pretty useful to my colleagues in piecing it together also.


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.


I end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect. For code, I'd prefer the time go into designing a cleaner interface and making what calls do obvious.

That said, I find high-level documentation for larger systems to be very valuable. I also find Python's docs to be lacking compared to Java's; I'm often left wondering about the definition of what type is returned, exactly what parameters should be, and which exceptions are raised. Java's docs are very explicit about all these things.


>end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect.

I'm a pretty firm believer that documentation has to live next to the code. Otherwise it's nearly guaranteed to be out of date and/or incomplete


100%

Thoroughly commented code tends to end up a couple changes out of date. A separate file in the same directory ends up a couple major refactors out of date. A separate file in a separate system ends up a couple company-wide reorgs out of date.


I agree. I'd like my documents to contain overview, intent, and exceptions. The actual implementation I can look up in the code. Also generated stuff is appreciated, like Swagger.

You should be reading the source all of the time. The point of documentation is to tell you what the code doesn't. If it tells you the same, you should delete the documentation.


I just use headerdoc-type stuff. Been doing it for decades.

It works very well, and doesn't really add any overhead to my work.

I write about how I do documentation here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

It's a long read, because it's a big topic.


That's useful, but only covers documenting the code, and API usage.

Depending on the project, various other documents may be required, e.g. installation guide, user guide, operations manual, architecture diagrams, networking diagrams, module/component diagrams, information flow diagrams, high-level design, low-level design, docs at various "views" (such as "business view", "information view", "technology view"), design decision tracker, ontology...


Absolutely. I do those, as well. Here's a rather more intense example: https://riftvalleysoftware.com/work/open-source-projects/#ba...

I'm actually in the middle of using Postman to generate a more "modern" inline docset for a new engineer that is coming into a project that uses that server.

But I also like to keep docs to a bare minimum, as they become what I term "concrete galoshes": https://littlegreenviper.com/miscellany/concrete-galoshes/

We need to be very careful, as the docs can prevent agility, in a big way.

I find that if I can keep the docs pinned to the code, itself, as much as possible, it helps to keep some flexibility.


Ah nice, it's refreshing to see that level of documentation for an OSS project, even if it started as a commercial project.

Totally agree about not having too much documentation - sometimes outdated documentations is worse than no documentation at all.


One can hope, but sadly I don't think it's going to be an easy shift.

People managing work, from what I've seen, still prefer to babble over their scribbled 5 basic points than taking the time to do their job and create relevant textual information. Then you listen, you take notes, and then you go and produce whatever documentation of the objective is required to at least understand if it's going to work. Of course you still will have gaps in your understanding, so then more calls, and repeat. In the end, unnecessary/missing features, a whole bunch of time wasted in crap, deadlines missed, burnt time, all of which could have been avoided if someone just had taken the time to do their supposed job - this is not to say it wouldn't have to be discussed, or that there's no need for back and forth and calls, etc, it's just instead of starting halfway you start from -50% or something.

Even in outsourcing platforms there's been a shift contrary to that. At least two years ago and before that, video calls or calls weren't really usual unless you were in some months long collaboration - now even there everyone expects video calls on the interview... It doesn't matter if it's a $100 one time job or whatever.


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.


Also "if the code is clear, it documents itself". Which in my opinion completely misses the point. Good documentation doesn't tell you what the code is doing, it tells you why it's not doing something else.


That's a useful take,

Code says what is done. Docs says why


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.


But there are circumstances where documentation would be outdated before it is finished.

Trying to write ops documentation on an unfinished project can be this way.


Exactly. That's not a documentation problem, that's a writing problem. A lot of tech people don't enjoy writing, but also they're sometimes not very good at predicting or empathizing with the future reader of their writing. Sometimes that's also manifested in speaking, and failing to context frame concepts, arguments and ideas before jumping into excruciating detail. Senior managers notice this, and this limits your career.

So I argue that the issue is writing skills, of which technical documentation is a subset speciality of writing skills. I will add, similar to math problems or programming, writing wants you to do it over and over so it can get better.


> A lot of tech people don't enjoy writing, but also they're sometimes not very good at predicting or empathizing with the future reader of their writing.

Agreed, wholeheartedly. Will hitchhike on your comment to recommend two things: Brett Victor's pdf stash [1] and, specifically, the Walter Ong essay "The Writer's Audience is Always a Fiction"[2].

Long story short, we form our audiences by subjecting them to our writing. In writing software documentation, we are implicitly informing the next generation's thought by the simple power dynamic that underlies all technical documentation: "you must understand this in order to do your job properly".

It is no wonder that "form", "inform", and "information" are such closely related words.

We dictate the level of rigor and intelligibility we expect out of our technical documentation, when we write technical documents. It almost sounds like a tautology when put this way, but "bad docs" are exclusively the result of a professional culture that puts up with the existence of bad docs. I've been there; too tired and overworked to care about writing something properly, or wanting to avoid writing a doc enough that I setup some autodoc thing and called it a day. We literally don't get paid for writing documentation.

But good documentation is what made us into good developers (if we are good developers). We should get paid for doing that...

[1] http://worrydream.com/refs/

[2] http://worrydream.com/refs/Ong%20-%20The%20Writer's%20Audien...


> effectively communicating ideas through text was one of the most underrated skills in software engineering

Absolutely. So many hour long meetings could be shortened by better communication skills (just more targeted), or even a small email chain.

Communicating in short form confidently is a skill. Many people, including myself (something I've been working on) struggle with saying something that was a complete idea in a meeting and not stopping because they feel like they need to say more. Short and sweet is the way to go pretty much whenever you can, for technical work that is.


And many many people don't do it well. On both ends. Reading is a skill too.

I find 'small email chains' don't help at all. Too many people just don't read past the first sentence or paragraph. And email is slow.

I usually 'escalate' quickly. Support didn't understand a ticket comment I made on how this isn't a bug or why there really is a workaround for it?

I send them an IM trying to coax it out of them/get them to understand for a few minutes. Doesn't work? Quick call and do screen sharing. Problem usually solved after a few minutes. Problem is they might stay longer than that took just to 'catch up' ;)

This is really not that different from when we were all at the office just that the last part would be walking over to their office and looking at the computer together. In some situations that makes it even easier nowadays because I don't need to take an elevator down 20 stories and back up again after.

Having asynchronous means of communication is great. But as soon as the back and forth is more than maybe twice on each side, there's probably a miscommunication happening somehow that will be much easier to get solved with a really short feedback loop. Some people you have to call right away coz they just type soooooo slowly ;)


Not only in writing but also in plain English. I see situations like described below over and over.

Example 1 - too much details. Morning stand up. Manager: what's the status of that new feature. Senior Engineer: well I tried to call that service but it was timing out so I spoke to Bob and he said to check with DBA on why that stored procedure but it's so slow and turns out index is missing so we tried to add it but mysql and varchar something fckn something...

Dude couldn't you just tell it's delayed due to DB and then expand if needed.

Example 2 - insufficient details I return from the meeting and discover avalanche of emails, chat messages and urgent meeting invite, all with same topic - "Blah service fails, we are blocked" but no details apart from that. On the call I get description of the problem - blah service fails and how everyone is blocked and how infinitely critical it is and what ETA for resolution would be. What endpoint? How does it fail - timeout, connection aborted, 503 response, 200 response but with error message?


I like documentation that starts with a minimal but functional example, followed by the most common additions to improve the solution and finally a complete documentation of all functions.

Having links to actual code, like GoDocs have it, is something I appreciate too.


Effective communicating is a crucial part of every job. I think in software engineering, a lot of us are introverts who want to deprioritize this soft skill, but the truth is still that people matter more than the code.

And communicating gets even more important the higher up you move in your seniority.


Documentation can also be anything. Is it your initial RFC or ADR, or is it a spec? Is it a set of product requirements? Is it inline with your code so it produces a manual when you build it? Is it a set of articles or tutorials written after the fact? Is it a README?


Effectively communicating through text amplified due to WFH. If you can avoid syncing up on video chat and resolve something with a couple of back and forth messages. That's a win


I find documentation to be relatively straightforward to write. The issue for me is sitting down and slogging through the activity, which seems almost antithetical to writing code. It's like doubling the work in a far less rewarding way. And then you have to go back and update it any time the code changes. It's a sort of necessary evil I suppose...I think most of the problem is that devs just can't be fucked to take the time, and I'm often guilty.


>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.

I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along," when really they are just subpar communicators.

Short story, I am helping my current company switch from a monolith to service-oriented architecture, and in the process have built a framework for spinning up new fully-deployable services from scratch that gets engineers 90% of the way there (minus the business logic). I have a strong vision for how it works and had a dozen-page RFC accepted by the engineering team for it. Yet there are engineers who think I am making it up as I go (I have been asked this indirectly), without any vision guiding the pieces into place. I have chalked up this feedback to me needing to improve my communication of the vision.

So the post's response of "I realized that he's making it up as he goes along like the rest of us" is disturbing because it makes me realize just how difficult communicating a vision is... if this hero that the poster paid $5k to go see can't even convince one of their fans, what chance do normal people like you and I have of convincing people that we're not making it up as we go?

>EDIT: I realize that I am posting under the assumption that the person's hero does in fact know what he's doing. If he truly is making it up as he goes, the above doesn't apply.


What is wrong with making it up as you go? I mean everything I've ever built I had a notion of what I was doing but most of the real work was in the details. Anyone could say I was making it up as I go. I'd be like yeah, if I knew completely how to do it, I'd already be finished it.

Then there's the times where you think you know exactly what you're doing and after going down a road you realize it's the wrong way. Failing to learn and see the signs and make the embarrassing declaration that you got lost and need to turn around is never good. But some people just keep driving. It's hard though when there's a big line of cars behind you that think you actually know where you are headed.


Nothing wrong with making it up as you go, and I didn't mean to sound like I was knocking it, if I did. Sometimes everyone fumbles around trying to find solutions that work...it's a totally valid way to approach some problems.

Sometimes it's a hybrid of knowing what you are doing but not knowing the implementation specifics. You know you need to connect high-level pieces A, B, and C with specific constraints, but it won't be until you get into the low-level implementation that you'll know if it is indeed possible. I think that's an example of both having a vision and also improvising as you go.

I am concerned about how to effectively communicate visions to people, because it gets everyone rowing in the same direction. If nobody thinks that you have a vision, when you do, there is no reason they should choose your direction vs just do their own thing.


Ok this is helpful. If people are doing their own thing and not following the established, agreed on (or even dictated) way or vision, then you need to figure out why if you are the lead.

Maybe it is communication related. Does everyone know that this is the way they should do something? But they still don't? Have you created docs and edicts around these areas? Have you been assertive in code reviews? Have you been proactive and requested design sessions before a lot of work was done?

Has a decision been formally communicated? I see this step not happening enough, people are hesitant to be authoritative after a discussion on architectural concerns. If you are the lead, that needs to happen.

Most of the time it's simply a case of them not knowing how to do it. People are afraid to show their lack of skill and knowledge and ask for help. They get deadline pressure and deliver their default way.

Have you provided a feature or cut through the system that shows this vision for people to follow? Maybe example code, resources on the web that go very deep into the ideas and tactics? Have you paired with them to help them get started or get over obstacles. Perhaps pair your most senior person with juniors for a while to get them on the same page and capable with this vision.


Using a phrase like "fumbles around" still sounds like you're placing it on a lower rung, whereas I would say that basically everything I've ever done has been an iterative, collaborative process, including in situations where I'm highly confident of both the problem domain and technology choices. There are always going to be new discoveries made during implementation, and you can't have a written-in-stone design doc that prevents anyone on the team suggesting a refinement.

For myself as an opinionated person in a devops role, the vision that I try to communicate to my colleagues is mostly broad principles like configuration as code, helping people help themselves, consolidation of systems, and then some more pointed specifics like don't touch prod, don't make changes without a consensus, start by understanding why it's the way it is before changing it, etc.


>I am concerned about how to effectively communicate visions to people, because it gets everyone rowing in the same direction. If nobody thinks that you have a vision, when you do, there is no reason they should choose your direction vs just do their own thing.

I used to have visions. Now I have collaborative design discussions driven by some starting designs. I found that if people don't contribute to the overall design then they have little impetus to actually understand it. This tends to lead to a better design and a more engaged team so a win on all counts.


They are far less rigid at this stage as they haven't invested a lot of coding time.

100% this.


> What is wrong with making it up as you go?

Nothing if you're good at it. But if you're hoping to learn something from someone, it is pretty disappointing. How to make it up as you go along is far less teachable.


It really depends.

I take this really just to mean "everyone has faults".

People often idealize heroes and think of them as beyond human. If you do that and met your hero then your illusion will often be shattered. But the problem is just that you were putting them on an unreasonable pedestal.

Of course some people are frauds and some people have no idea what they are doing but manage to make people think they do. But I didn't read this as being one of those situations. Just someone they saw as beyond human being only human.


I like the phrase “kill your heroes”. Not literally, of course. But in your mind. They are just flawed people like everyone else that happen to have been mythologized. Learning more about your heroes often leads to disappointment.


I've recently found a podcast called "your favorite band sucks" that's along these lines. They have real criticisms of popular bands, but it's also a bit tounge-in-cheek. It's a nice contrast to the typical worship of rock bands. I think it's healthy to be able to enjoy something, or be inspired by someone, without buying into the mythology.


I have different take on this

I "know" guy who's conference speaker, so he knows other conference speakers, drinks vodka with them and so on.

He says there's significant amount of bullshit aka things that work nice on slides, things that only work cool in theory, but in practice they arent as great

I think that's what OP meant


A common meme I've seen recently is "no one knows what they're doing".

I think people like to believe this because it helps them cope with impostor syndrome, or maybe they think it puts them on even ground with people who do in fact know what they're doing.


My model for people who "know what they're doing" is that they tend to have a well-organized hierarchy of rules. At the base are principles; at the top are opinions.

The foundation tends to be pretty simple, deeply held, and unchanging, while the higher levels are increasingly fluid and specialized. The higher you get on this stack, the more "making it up as you go along" it becomes, but every improvised part is perched on something more stable.

They key to "knowing what you're doing" is organizing this hierarchy well, having the right supports in place to successfully guide improvisation and course-correction while steadily fortifying the foundation.


It's clearly not true in all circumstances. You can bet that an airline pilot has a very clear idea of what they are doing, and so will your dentist. Closer to home there are plenty of sub-fields in software where I'd be completely lost but when (say) we have to add a new endpoint to the webservice I work with, I absolutely don't have to make it up as I go along.

Your assessment of why people like to believe this seems spot on.


Even worst is the meme that “programming is just copy+pasting from stack overflow”


Because good senior programmers are rare (as can be observed if you post a job listing).

Most of this stuff comes from students / junior developers, where yes, they probably visit stack overflow every 20 minutes


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


"For some the productivity drops to zero without stack overflow."

And it is bad to be a newb? And even for experienced devs to go to stackoverflow regulary ... isn't it productive, to not always reinvent the wheel?

I can solve allmost everything on my own. But if I have a new problem, I assume someone else already had - I would be stupid, to figure it out on my own, when I could get a working solution in 5 min googling.

But I actually programm without internet connection most of the time, as I like being outside, away from noise (and wifi)


The issue does arise when you aren’t able to understand the problem space enough to realize that what you copied from stack overflow has a mistake or doesn’t fit the requirement you need (e.g. perhaps it doesn’t match your error handling architecture or so on).

That said, stack overflow can be a great source and I’ve written plenty of code with a comment pointing to a SO link to further explain a pattern or snippet for a future reader.


"The issue does arise when you aren’t able to understand the problem space enough to realize that what you copied from stack overflow has a mistake or doesn’t fit the requirement you need "

Yeah sure. A stupid programmer will remain a stupid programmer, even if he reaches a certain productivity by living off of stackoverflow ...


There is nothing wrong with copy pasting code from stack overflow.

I do see two kind of people doing that. One group learns from the code in order to become better, and can use it over and over to be more efficient. The other group doesn't care how it works and just wants to have a snippet that works.

The second group usually misses a curiosity, of which the effects show up in many more places than just copy pasting from stack overflow. They also tend to have a flatter learning curve. I don't want to generalize, but in this group you will encounter people who don't care about the difference between a list and a set, or think that code works when it compiles. In both cases the juniors know very little, but one grows and the other one doesn't (or less)

There is space for both in the world, but I prefer the first group in my team.


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.


I've done various rust and clojure projects by downloading a lot of git repos ahead of time for reference while on a long-haul flight. This works pretty well, but you need to do a bit of research ahead of time on which libraries you might want access to. This is probably slower, as you have to read source code and think more about the type signatures (rather than looking at some misc example), but if you have 15 hours, what else are you going to do?


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.

The criticism may depend on different values of "making it up as you go along", i.e., it may not mean so much "just wing it in ignorance" vs something like "even if you have many answers you don't yet have all of them, and new answers generate new questions exponentially...". So, perhaps less "everyone's ignorant" vs "we're all living in a land of many unknowns". But, yeah, he did find it disillusioning, and maybe is over-generalizing from a one-off experience (in contrast, I've done similar and was nothing but impressed, finding it is extremely valuable to learn from the best in a field).

How do you distinguish between what you do and "making it up as you go along"?


IME most people will generally appear to be making things up as they go – even if they have significant relevant experience. Every situation is unique, and experience tends to look more like having a list of techniques with varying degrees of expertise, rather than having a playbook for every situation. You have to look for the expertise rather than raw confidence.

In sports terms it would be something like a baseball pitcher being able to throw a great curveball, a great fastball, and an all right slider, and knowing roughly what situations to use them in. There will still be a high degree of randomness and mistakes will be made.


Agreed. What experience and talent gives you are instincts that improve the chances of whatever it is "you're making up as you go" working well.

I would much rather work with people who have a good track record of making it up as they go as opposed to people coming in with a fixed idea of how something should happen and are more likely to misapply whatever lessons led to those views (probably someone elses anyway).


> built a framework for spinning up new fully-deployable services from scratch that gets engineers 90% of the way there (minus the business logic)

I'm guessing that this was based on first-hand experience building such services and witnessing engineers struggle getting new services up. And not so much that you've had specific training or past experience in developing bootstrapping frameworks. This would be my definition of making it up as you go and is great way to do it. Another way is learning how to make bootstrapping frameworks and applying it wherever you can which doesn't go as well.


Related thing I'd add: be very careful about taking a dream job; I've seen this happen a few times--it's likely to disappoint. Also dating a minor celebrity crush.


In your particular instance, I would have collaborated with a single team to work on converting a single service over to the new framework. Once some success was made, it would be much easier to make traction with other projects and teams. Also, a vision or a plan doesn't mean you're not winging things as you go.


Building a new framework should be way at the bottom of your list of things to consider. If you do, please make it a blackbox. It's tiring how many details one often needs to get into before being able to do something they could have summarized in a sentence the whole time. But this is a general issue!


Also which "hero" is charging 5k for courses and what form does the course take?

(I work at Red Hat, and my programming heroes are also my colleagues.)


I wonder if it was a course at something like a conference? I think those are expensive. I can't imagine anyone is charging 5k that seems absurd


It just means don't blindly trust the experts.


The problem is idealizing such people in the first place. Sure, they may have had incredible achievements, but they're humans at the end of the day.


> Hacker News and r/Programming is only good to get general ideas and keep up-to-date, the comments are almost worthless

That's a weird one. I don't know anything about that subreddit, but HN comments are frequently great. I submit stuff because I want there to be HN comments on it for me to read. I typically read the comments first and only bother opening the link if they were interesting.


See: https://danluu.com/hn-comments/

>HN comments are terrible. On any topic I’m informed about, the vast majority of comments are pretty clearly wrong. ...

>And yet, I haven’t found a public internet forum with better technical commentary. On topics I'm familiar with, while it's rare that a thread will have even a single comment that's well-informed, when those comments appear, they usually float to the top. On other forums, well-informed comments are either non-existent or get buried by reasonable sounding but totally wrong comments when they appear, and they appear even more rarely than on HN.


Pretty much this. HN is still gazillion times better than everything else on the internet. And that is excluding the absolute gold comment from members that were part of those battle stories.

It is also a reason why I dont want to mention or see HN links in mainstream media. Although I think most reporters sort of know this as well and tend to not mention or link to HN as source.


My experience of Hacker News comments is not positive. They tend to be very convincing but actually kinda bullshit (or just vacuous), which is arguably a lot worse than communities that are transparent.

That’s what Dan is saying - but once in awhile you find a pearl in an area you know enough about to confirm.

Otherwise it’s best to assume everything you read here is full of it.


I was responding to the idea that it's better than everywhere else on the internet. That hasn't really been my experience. Discord is better, StackOverflow is better, even Reddit is often better if you're looking at specialist communities.

But to be honest I rarely find pearls here. Even many of the "pearls" in the article are just well-written articulations of stuff that is... kind of obvious. Some are inversions of ordinary wisdom for the sake of inversion. Only some carry new information.

I find the most valuable stuff here tends to be arguments where someone knows their shit but is going against the grain, and that person will usually be flagged into oblivion. But there aren't many places you see someone like that responding in context to the mainstream dogma.

---

Interestingly though, reading through it I explicitly remember a lot of the comments he quoted, e.g. the FedEx Airport one (which was really interesting). It's kind of crazy to think the site is small enough that we're all reading the same good stuff.


The most valuable to me are when someone with major historical domain knowledge stops by to detail some historical event in the IT world.

Unfiltered stories from those who were there are often useful, even if their memory of how it transpired may not be entirely accurate.


Oooooh, good point. Yes, posts like that are great.

Yep, it's brilliant. I think there's a kind of unspoken rule that you don't talk about it too much - because it preserves it from the mainstream rubbish.

Obviously HN commenters like us are going to think that. Honestly, I bet even YouTube commenters would say the same about their own community.


That’s not obvious to me at all. I comment on both YouTube and HN, and I don’t feel I’m part of any “community”. I just think the quality of the average, highly upvoted HN comment is about 100 times greater than the equivalent YouTube comment.

I frequently bookmark both an article + its HN thread when the comments are full of related opinions, info, and links.


You should check bitcoin early-days posts

R/crypto has a great community fwiw


>I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

Full stack compresses two jobs into one. It's purely for cost-savings. They're paid so little because companies revert to "well, you can still only do 8 hours, so you do half as much of each", but really that's just them trying to weasel out of paying for knowledge. They also blur the lines by putting full stack along-side other devs, even though the other devs may not have invested the same time to gain as much knowledge as full stack.

When you take a full stack job, you undervalue your knowledge (and the time invested) and are selling it for roughly half of what it's worth.


I've been a "full-stack" developer at large tech companies, and my experience is there at least it means "frontend developer who can put together a basic API server". My fellow full-stack developers and I would spend most of our time building out frontends, which was generally regarded by others as challenging and specialized work, and maybe 20% of the time adding API endpoints to fetch or update some data, which was considered straightforward.[0]

Not having to wait for some other engineer to make the backends made us a lot more efficient. It definitely was rewarding to be able to complete products end-to-end.

Hiring standards and pay were the same as for any engineer, at least in FAANG.

[0] Yeah, occasionally we had to optimize some SQL queries or whatever but we're competent engineers, we can figure it out even if it's not what we do every day.


> my experience [full-stack] means "frontend developer who can put together a basic API server"

This is 100% accurate in my experience too, and it's also true in the other way around: "full-stack" means backend developer who can put a basic SPA using React/Vue.

From the frontend perspective: they call themselves full-stacks for knowing how to spin up a NodeJS HTTP Server powered by Express with MongoDB inserting JSON in the database. But they are missing:

- AWS/cloud computing: not necessarily creating the infrastructure (although that's a must on more senior levels), but how to orchestrate the different components together.

- databases: why SQL/NoSQL, beyond basic SELECTs, knowing how to properly add indexes, debug why queries are slow, modeling, understanding locks implications and transaction levels, and so on.

- tooling: how to set up a bundler, linter and formatter, testing, CI/CD. This overlaps a bit with the responsibilities of the DevOps engineer, but a full-stack should know at least on intermediate level all of those things. I can't say how many times I've seen "senior full-stacks" that had no clue about how webpack worked at all.

From the backend perspective: they call themselves full-stacks for knowing how to spin up a React/Vue app that does basic CRUD operations using forms, powered by a UI framework like Material UI. But they are missing:

- CSS: most will find CSS hard/annoying and won't bother understanding at all how it works even on a fundamental level, will defer to hacks most of the time to make things work, especially when it comes to adjusting for edge cases like responsive design or cross-browser support.

- the DOM: normally they don't understand it at all, or to a very limited extent.

- Web vitals: how to measure and makes things faster and performant—not really including here overly optimized, but just making sure your app is 60fps or close to that most of the time. Usually when things get slow either on the network side or in the app itself, those engineers will blame is the framework/library, not their misusage of it.

--

Those lists are definitely non-exhaustive, as I didn't even mention more advanced stuff like protocols (how HTTP works? most can't answer), caching, etc etc, but you can get the point I'm trying to make:

The problem with the term full-stack is that only very few engineers really are sufficiently great on both sides of the stack and could say that they mastered both, simply because there's just too much to learn! Frontend has become so much more complex with SPAs compared when it was about rendering static HTML with some CSS and basic behavior with jQuery. Same for backend with the advent of cloud computing and several types of databases.

I've been coding professionally for a decade and I've met only a single engineer that I'd consider him full-stack (he checked all those boxes I mentioned and more). I think I would also include myself, because I spent 50% of my career spent as a front-end engineer, became senior, then I transitioned to back-end engineering because it pays the same or more and it's less stressful (for most of the regular companies that most of us work at). My current title is "principal full stack engineer", but in practice I only do backend/devops, I don't actively code front-end but I keep up with the industry by following the new trends and testing things here and there in personal projects.

Ultimately, I believe for being a full-stack engineer you have to be first a front-end (or back-end engineer) then learn the other, what we have today is most people doing the same from the very beginning of their careers and they either go deep on a single one or in none of them.


Full stack is not really a skill level qualifier - that's what junior, senior, principal, staff, etc. are for. It means you work in different areas and can't say "oh I don't do that work here" when someone gives you work in those areas. People call themselves front or back end engineers long before they've mastered it, and you don't have to wait for full stack either.

The front or backend bias you and your parent's comment talk about are team specific things so you don't give a hard front-end task to someone who is biased towards the backend. That still means they can take the less difficult tickets.

You can replace full stack for your example with "extremely good/talented/gifted engineer" and I'm almost sure it has nothing to do with the full stack label because it's the only example in a decade you've found.

But also the jobs that they get feed back into what they call themselves. So even if that's your example, it isn't how the business defines it, which IMO is ultimately why it's just a cost savings label to get people to work harder for similar amounts of pay as front or backend people.


There's also an issue with how many full stack web developers who are actually capable of doing all the things he lists.

My experience is that at some scale it works out okay, but beyond a certain point it just falls flat for most. We deal with insanely talented developers, who will trash a database, because it don't understand how it works. Talented JavaScript developers, who don't really understand how HTTP works... or load balancers, or caching... or webservers. Sometimes you get these fantastic software machines as deliverables, complex, you can't monitor them, or configure much, and the it just implements a basic feature of HA-Proxy or Apache, but badly.

My point is that they should be paid poorly, because they fail to be excellent at every part of their job, but rather than: Yes, this should in most cases not even be a job title. If you find someone who can do all of this well, you almost can't overpay, but are you really sure that you want to tie everything up on one person anyway?


It is not 2 jobs in 1.

Full-stack developer knows some frontend, some backend, some sql. They are paid good money because they are convenient, not for their knowledge. A dev who does only one thing knows way more about it that a team of full-stack devs.

Full-stack devs earn a lot and will probably earn only more in the future.

This is mostly a result of tech advancements like cloud infrastructure, tools etc that takes all the hardest things from you - like managing a DB, implementing security, managing infrastructure, deployments etc.

You don't need deep experts because of it, generalists are perfect for quickly shipping new features.


I would do "full-stack" over a decade ago, when there was less of the notion of "front-end engineer" (which still sound a bit ridiculous to me) - the front-end was mostly HTML and CSS. It was a good experience, to go from requirements gathering to the database schema and back to presentation - it helped me see the whole picture.


Why is everyone saying they’re underpaid?

You can make doctor level salary at the ceiling if you move to a FAANG as a full stack dev.

The fact that boot camps even exist shows that it’s not that difficult of a job.

Other industries boot camps don’t even exist.


there is plenty of other software engineering work that is way more complicated than full stack web dev, and there are a lot of web devs.


What common position pays better than full stack?


"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.


You have a great point, but let's balance this out with a few of the author's other comments.

- OP uses the phrasing senior engineer.

- Never worked for FAANG. This is relevant because $120k + bonus/benefits is basically a FAANG new grad. Fairly normal for SV tech companies.

- Those numbers likely provide a solid standard of living, but as a senior engineer you are likely underpaid.

- Esoteric and proprietary knowledge means if you choose to go elsewhere, you will be at a competitive disadvantage compared to using industry standard tools. There are of course tradeoffs and lots of general learning that comes with experience, but all other things equal it's a disadvantage.

> I guess those numbers also explain why the author can recommend maxing out the 401k

Yes, but again fairly typical for the target audience I think. There are even startups trying to target this market to optimize the flow of money from salary -> 401k -> post tax contributions/megabackdoor -> other investments, brokerage accounts, etc., e.g. https://www.helloplaybook.com/

Just as a sanity check, BLS suggests the median SWE wages work out to ~$110k.

https://www.bls.gov/ooh/computer-and-information-technology/...


I'm an intermediate dev, masters degree, 9 years experience, non-FAANG, higher cost of living area (not SV, NYC or NVA), and work with obscure tech and proprietary tools.

It sucks that I suck. Oh well.


You might suck, but it seems more likely that you're getting ripped off by an employer who hopes you don't know what your skills are worth.

Are you on LinkedIn? Do you ever speak with recruiters about other opportunities? That's a great way to get a feel for the 'market rate' for your skillset in your area. When's the last time you changed jobs?


They're stuck because they work with proprietary tools on obscure tech. Nobody else wants them because their experience doesn't translate.

I recently made the transition but it was extremely difficult. I ended up with 1 offer after ~10 or so interviews and ~50 or so applications.


Yeah, this is my situation. I am AWS certified and started working on a team that uses it, sort of. So maybe I can transition off of there in a year or two because the subject matter sucks.


Programming is programming no matter the language, don't let anyone tell you otherwise. They are all just tools. If you have a masters degree you should be able to pick up anything proficiently in a matter of a few months, just grok the existing codebase as much as you can.


The programming part is easy to pick up. The tools and ops parts are more difficult, mostly because there are so many. And we are a 'microservices' shop (read distributed monolith). I don't get to read/work a single system or language. One sprint/day I might be in ECS Java, the next might be Python Lambda, then no code stuff like Splunk and Tableau. There are a bunch of minor and bureaucratic tasks too.

The real problem is I deal with this sort of stuff. I started doing analysis about modifying a system to provide a new field to another system for the purpose of reporting. After spending a day looking at it, they pulled the story because they didn't actually need that field. And this isn't a one time thing - pulling back work. Then they give me BS stuff. They wanted me to increase the code coverage on an app that we were going to transfer to another team. The target percentage - 100%. It was already at 97% line 98% branch. Why am I wasting my time on this miserable task?


Dude run from your current employer. I actually transitioned into software dev after working as a Mech Eng after 2 years and I started at $120k. With you experience I feel like you could do way better.


Glassdoor's market rate/comp tool says I'm actually making market rate for the area.

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 almost assuredly more desirable in this market than you think. Consider making finding a new job your new hobby.


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.


"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.


Software dev, then manager.

Every place I've worked I've seen the same thing. Work/life balance is stressed as being important, BUT you will totally end up working extra hours if you cave to implicit pressures others set on you (oftentimes the business, product, etc). Someone will try and schedule you for a meeting at 5 PM, or say "we need this by next week", or whatever. And every place, I've said "No". Sometimes it's "I can't make that, I have to be home", sometimes it's "That isn't what we committed to this sprint" or even "That's what we committed but the sprint has been broken because (other thing)". Occasionally it's even been "Hey, we ran into something unexpected; even though we committed to that it isn't going to happen by that date".

On call pages happen; I always take time off the next day. As a manager, I -tell- my team to take time off the next day if they get paged.

Even where I am now, where I will have meetings scheduled at 7 AM, and 6 PM, routinely, I just close my laptop up in the middle of the day. Sometimes I'll even book time pre-emptively just to prevent people from trying to schedule me straight through (and thus leading to a > 8 hour day).

Etc. The perverse thing is that by doing this people actually get a -better- impression of me. There's an element of confidence; couple that with the fact I do deliver, and they don't question it or push back on it. And ultimately even if they wheedle enough I say "okay, fine, yeah, I have to talk to the guys in China; 6 PM meeting it is", I just book time 9-5 for my own stuff, or (when in the office), leave at like 3 so I can get home, unwind a bit, have dinner, and take that call, and still only work 8 hours.

I can't speak to Philly; you might be right. If you're tied to the area, consider remote. If you're not tied to the area, consider looking for things outside of it.


That sounds nice.

I've found that if I only work 8 hours they will say that I'm not getting things done fast enough. It makes sense if they are comparing you to people who work more. I know one department where the tech leads all work 10 hours consistently.

I was once in a discussion about how to get to a senior dev position (after filling the role of senior dev for a year and tech lead for another year). I was told I had to work an extra hour per day. That's a 13% increase for a 7% raise and a role with higher expectations...


So a couple of things to note there.

First, a great deal of research shows that working past 8 hours of day for long stretches actually -reduces- overall output compared with working 8. Now, to be fair, the bulk of this research was done on physical labor, not mental, but interestingly, what research -has- been done on mental found the same thing, except the actual hours was more like...6.

Second, you're working at a place that actively -encourages- you to work unpaid overtime. That sees it happening and rather than saying "what can we do to prevent this and not risk burnout" instead says "good. Keep at it". If you're salaried, you're effectively getting paid a lower hourly rate for the work you're doing. So...not to beat this horse again...but...look for another job. It doesn't sound like the pay is great, it doesn't sound like the environment is great. The only thing keeping you there is a belief you can't get anything better; maybe that's true, maybe it isn't, but it certainly will be true if you don't at least look.

Get yourself on Linkedin. Find a tech focused resume writing service to help you with verbiage, both for your LinkedIn profile and your resume. Let recruiters know you're looking on LinkedIn (https://www.linkedin.com/help/linkedin/answer/67405/let-recr...). Start looking for roles in your area, and remote (and in any area you'd be willing to relocate to). That sounds like a better use of an hour a day than giving it, for the same price (free), to your current company, in the hopes of a 7% raise and higher expectations in the future.


Get. Out.


Obscure tech and proprietary tools do translate… if you can translate them.

Programming languages are all the same, so learn 3 or 4 new ones and discover that you can probably write in any language for an interview (then do some in relatively unfamiliar languages for kicks and giggles to practice).

Tech is all the same. Take data in, poop data out. That’s the whole job. The formats and protocols change, but once you starting thinking about your stacks as data-in, data-out, they all start looking the same.

Make video games or hardware drivers from scratch, those are the hardest things to make. Video games from complexity overload, and hardware drivers from interface complexity.


I already know Python, Java, Java for Android, Neoxam script, scripts (bash, bat), and Angular to some degree. I've also used JS, AngularJS, C++, C#, powershell, assembly (Intel), and COBOL in the past. So yeah, stuff translates and it isn't that hard to learn a new language (neoxam is probably the hardest since there is limited documentation and examples).

I don't have any interests in games or drivers. Those aren't applicable in my company either. I am currently working on an Angular site. I will host it on S3 with a Lambda and maybe SQS for a marketing email list. This is tech that we use at my job, and many other places.


I really didn't mean for the comment to come across that way. I fully agreed with "it sounds great because it is great". I just wanted to provide another perspective too.


No, I completely get that. I'm just adding some of my background to show my thoughts. I know there are other areas and other people that command higher prices.


Learn the skills for the job you want, claim you do that stuff on your current resume (within reason), and jump ship. Most prospective employers won't push too hard with needing references from your current place of employment. Find your best mate at your last job, edit that portion of your resume, and fill them in on the details.


I've been at the same company for 9 years straight out of college. The company doesn't allow employees to give any references for people who are leaving.


If you're in the US, there is only an -infinitesimal- chance that they'll actually ask for references for a software job.

They'll likely run a background check and make sure your resume isn't obviously lying (they'll confirm start/end dates and title, basically), and make sure you're not a criminal, MAYBE do a credit and/or drug test.


>This is relevant because $120k + bonus/benefits is basically a FAANG new grad. Fairly normal for SV tech companies.

There were a few post on HN recently about fresh grad asking for / being paid $200K and anything lower they felt they were feeling lowballed.

For those of us outside US we could never quite grasp whether something is true or not. Salary across the pond is just incomprehensible.


$200k for salary for a new grad strikes me as being on the (unrealistically?) high side. You'd need to be quite talented and have negotiating leverage for this. FAANG generally won't offer this out the gate. That kind of salary would buy senior devs no problem, even in big tech cities.

$200k total comp, absolutely. A standard new grad offer with no negotiation might be something like $120k salary, $25k cash, $120k options vesting over 4 years with 6 month periods. So in the first year, no negotiation, you're taking home $177k pre-tax. I know people who have gotten up to $60k cash bonuses (split over two years) out of college, simply by having another offer.


I think they are being serious. If you're in silicon valley, I could see $200k being a new grad salary. I wouldn't move there for less than that. The cost of living is extremely high in that area. The vast majority of areas would have much lower salaries. My starting salary was less than $60k. After 9 years and a masters it's still under $100k in a medium-high cost of living area. Median salary for a developer is about $110k in the US.

Meant to reply to you but replied to parent by accident. $200k total comp seems plausible. $200k salary seems like a bit of a stretch to me. Companies would much rather give you a fat cash bonus or stock than raise the salary so high.

This rings home for me as well. I remember my (now ex) wife saying she was going to quit working and be a stay at home mom the day I hit $100k salary. Effectively cutting it in half economically. I feel like folks who say these kind of recommendations also need to preface the fact that not everyone can afford to. I couldn’t afford to put anything in a 401k for years.


My prior manager said something about everyone should be contributing the max. Easy for him to say as a manager... with a physician as a wife.


> It's not important to do what I like. It's more important to do what I don't hate.

This one has started to dawn on me. I'm never going to love my job as much as I love my personal projects, so a job that I don't get very excited about but doesn't drain my energy is better than one that I get somewhat excited about but does drain my energy (not that it's impossible to have both, but it's rare)


This is a very pessimistic long-term view, in my opinion.

Life is extremely, infinitesimally short. If it's at all possible for you, you should try to spend as much of it as you can doing things you love. I know many people can't, but it's bleak to just give up and permanently settle, I think. (Especially if you don't currently have any dependents who rely on you; it changes the equation if you do.)


I don't look at it that way at all. I'm choosing to conserve my finite energy for the things that matter most. It's all about priorities: of course I would like to have a job that I'm both excited about and not too stressed about, but I can be happy and fulfilled with one that simply doesn't dominate my life (in terms of time or energy, because those are separate things), because my job is not my life. And being uncompromising about having a job that really excites you can force you to make all sorts of other sacrifices (time, stress, risk, maybe even things like money and lifestyle), which is where the prioritization comes in.


This is a very western view on life.


Maybe. I'm definitely not necessarily saying it in terms of work or career or anything like that. Just in general, I get a little depressed at the idea of just slogging through most of one's hours for most of one's days in existence.

This is a really really big one if you ask me.

It seems to me that many if not most people I meet fall into one of two camps.

The folks that just don't care at all and do the minimal amount of work they can get away with not to get fired. The other side is folks that care so much about it that they spend so much energy on as to ultimately be unhealthy for them and also making it worse for the rest of us (not taking vacation, unpaid overtime etc.

It is very rare to find people that care 100% while at work. But after ~40 hours each week that's it. Sure I'll stay later for that one meeting that's sorta important and needs to start at 4:30p.m. But you better not try that every day from now on. Want me to be on call for a fixed rate that has nothing to do with my salary? I can't log an hour for a 5 minute call at 1am and I can't take time off in lieu? Good luck getting me on that rotation!


I made this exact choice about 5 years ago and my life has dramatically improved.


>> Third party recruiters are leeches

Can confirm this and it was surprise for me when I discovered it. I assumed they would try to maximize $$ in my offer in order to maximize their profit. Yet most of them were trying to get offer accepted as quick as possible. Seems like more offers with less money in each is preferred over less offers with more money in each.


The same dynamic occurs with real estate agents. A successful agent optimises for quick sales, while giving the appearance of trying to get the best price. Very important to know when dealing with agents if either selling or buying a home.


To be more explicit: as a buyer, especially in a tight market, the seller’s agent will often do things or reveal information to the buyers benefit (against the interests of the seller they are supposed to represent).

There are “rules” to how the game is played, and how the information is revealed, and a lot of it seems hidden (in fact I have seen agents that don’t understand the perverse incentives!). A seller’s agent will usually need to make sure they have deniability, and they will prefer options where the vendor remains happy (so the vendor will use them again, and recommend the agent to other sellers).

I have only a very little experience, and none in the USA, but that was what I noticed in my own country.

It surprises me how little effort people put into understanding the game, given that playing it well can easily make the same difference as many years of income.


Some real estate agents will, if asked, agree to a more top-heavy commission -- e.g. instead of x% of the total sale price, y% of the amount over $z. (I don't know the exact details, but my dad did this when selling his flat.)


I think someone like Derek Sivers (maybe not actually him) talked about doing this. From what I remember, it was quite painful finding one who would agree to it, and was probably only possible because it was a stand out property.

This would likely be more difficult for an average person to pull off, but can be a great mutual win if you pull it off.


A quick tip for homebuyers/sellers to save on realtor fees. Contact the title company and they'll gladly tell you what you need to do to close the loan. Maybe not ASAP, but they are more vested in you doing the busy work and doing it right than they are the worthless realtors. Half the time realtors in my state wouldn't even sign the offer to purchase and include their info even though it's illegal and they can lose their license.


So given the buyer's agent fees come out of the sale price (which already reflects that commission), you're not really saving anything are you?

For the sellers, maybe, but I don't think I'd be at all comfortable selling a home without a (good) agent.

I'll 100% agree with you that most realtors are bad. The good ones are gold though.


Recruiters are like men on dating apps: spam as many people as possible without reading their profiles, treating people like objects


Who hurt you??


I've personally witnessed friends doing this as a man. A bit sad, and certainly not true of all men, but it's not false.


Interesting must be a strategy towards women selecting the top 10% only so men are not getting any matches. Getting matched before reading profiles saves tons time kind of makes sense. Then you can review and filter afterwards.

Why is that sad? Have you ever heard of speed dating? Similiar concept.


Well I've witnessed people not even looking much at the photos. Men do get matches, and I don't really agree with how factual or defined your initial statement is. I guess it's sad because of how arbitrary the selection is.


The selection is arbitrary because they're not the ones doing the selection, women are.

There's a well known study from OkCupid about this, women are way more selective so men only have very few matches a week (and some of those don't even respond) unless they try a lot.


That post actually might have started a genre in Reddit. Here's the next ones:

https://www.reddit.com/r/ExperiencedDevs/comments/nnw7yd/sob...

https://www.reddit.com/r/ExperiencedDevs/comments/noa841/sup...

I guess there will be more on their way.


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

Couldn't agree more


Yeah it's striking how this is not the majority opinion even amongst seniors. I'm mid career I still have to ask people very experienced why they always jump on the most long-winded complicated way to solve a problem, often simple enough to require very little.

There is still to this day the idea that we're supposed to plan to future like oracles or pad our resumes on the company's dime.


which is why leetcode makes no sense, as it focuses on premature optimization and writing the most advanced code possible which no freshman will be able to understand, at least not without dissecting it for a few hours first.


Isn't leetcode more about "passing" the technical interview white board questions? Not a reflection of what real world code looks like.


exactly, and that is the problem


> Algorithms and data strictures are important--to a point

For me, 90% of day-to-day algorithms use is not writing O(nm) or O(n^2) code, and knowing which data structures to use to avoid it (usually a hashtable, occasionally a heap or balanced tree).


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 <20 and likely to never be >50, yes. Otherwise, be careful; future people will not thank you for that timebomb.


It’s safer when it’s hard coded data and really bad versus dynamic data and sorta bad. I’d rather have O(n!) with a list of length six because it’s going to break hard before it gets to 20. O(n root(n)) on your customer list will slowly creep up and it would be easy to not notice.


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".


As the guy who has to deal with your code years later when the company is bigger...please think about the complexity, especially if it is a simple problem. Or not - that’s why I have a job

I don't know why you have been downvoted, you do have a point. Algorithms are tailored towards specific purposes. If you for example have something that runs with an n of about 5, and it's not in a hot path, the clear concise solution may well be better. Besides, with small n there is more to the cost of an algorithm than just its asymptotic growth.

However, to the point of the person you've replied to: It's good to know that stuff to be able to assess the situation in the first place.


I'm fond of saying that one of the big differences between theory and practice in CS is that in practice, we don't immediately drop the coefficients. Instead we study the problem to learn what the coefficients are and use that knowledge to guide our approach. For instance, there are times a linear search will just flat out beat a binary search due to cache effects.


But if you care about the coefficients the first time you write the code, you are prematurely optimizing. The theory here is wiser than it intended to be :).

First draft: don't be stupid with asymptotics as PP says.

*only if there is actual problem in prod or whatever: bust out the concrete measurements.


It may also be faster for small N, as the big O notation swallows the constant factor. It’s not accidental that standard lib’s sort algorithms will fall back to simple insertion sort at the end of recursion when n is small. (Though please correct me if I’m wrong, I’ve only once digged into the sort algorithm’s code in cpp and java’s std lib)


in my 25 years of software development, 90% of the time, you don't need to optimize the code and the worst solution in time complexity is totally fine. then there is another 8% of situations where trading in space for time complexity is the solution, i.e. using lookup tables. the remaining 1-2% of the cases you might need a combination of some data structures or containers from the STL or boost (in the case of C++). I've never had to roll some special version of a data structure or container or algorithm myself from scratch, and I work on some really complicated real time software.


> If I didn't learn something from the junior engineer or intern this past month, I wasn't paying attention.

Amen! Not just junior engineers. PMs, analysts, testers. We all have a lot to learn from the rest of the team!


> 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".


Pragmatic for me is knowing what’s wrong at compile time, and not being told much much later at runtime that I nested this array in a dictionary in an array wrong, or that my string is an integer.

I got older, stopped using python for exactly the reasons above (I just really felt that it was wasting my time for trivial reasons), and found mypy which made it bearable again.


Yeah, I'd be on board with that if 99% of the people talking about typed languages at the moment weren't using Typescript for use cases where you literally get instant feedback from hot reloading as you code.

Every time I see an example of a bug that TS would solve, it's something that I routinely find in 2 seconds by looking 10 degrees to the left at my second monitor and noticing the screen is white and there's some red text in the dev tools. "Compile time" doesn't mean anything if it consistently happens 0.5s before "run time".


As your application gets larger it's not that easy. Even if your code hot reloads all the time, getting to the piece of code that breaks might take 10 clicks or you are working on some feature that has quite a few combinations for use and/or settings that influence it. Maybe some feature flags thrown in. With this setting off and that feature flag on, suddenly your integer is a string. Boom runtime error but only because your QA thought of it when testing it 3 days after you already moved on to another ticket.


Groovy is a dynamic language that runs in the JVM, it lets you put @CompileStatic at the top of every class.

I believe typescript also has options for compiling statically.


> or that my string is an integer

Have you ever considered PHP?


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.


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


I keep getting downvoted on Reddit for stating that I personally hate TypeScript to the max. It ruined the beauty of JavaScript (once you know it, anyway, I understand there are difficulties for JS-novices) and I honest to goodness 100% do not EVER find myself thinking: "Gosh, thanks TypeScript!" - on the contrary, it's always: "For fuck's sake you stupid POS TypeScript, you're wasting my time for no benefit at all."

Strong-typed languages (especially in the damn browser) make no sense to me. It's not like we need to manage memory or anything.

20+ Years of experience here, and I hate TS with the passion of a thousand suns.


It might be your strong wording that people are responding to


The benefits of typing are, imo, largely unrelated to needing to manage memory


I disagree on strong typing. I think this is actually a good improvement that prevents many silly mistakes. But static typing and constant (re-)compilation is the part that kills the joy when creating software.


TypeScript isn’t strongly typed when doing “.map” on a non-array crashes at runtime: https://stackoverflow.com/questions/55229131/typescript-arra...

> Tests are important but TDD is a damn cult.

I don't see people commenting on this one! That may be a good thing because it means people are not questioning it :)


I like TDD when I’m mostly dealing with functional/library like code where I have a solid understanding of the interface/api.

Just put all the expected input/outputs in a big table test and iterate.

TDD is awful when you don’t have a clear idea about the interface and need to mock a whole bunch of internals that are likely to change.


Techniques aren't culty, people are. I've been practising TDD for years, but I've only ever heard of this cult in web forums.


Count yourself lucky then. I've tried to work with TDD cult members and it was one of the worst experiences of my professional life. A good sign that people have moved into the cult is when they start saying that people who are not using TDD are "unprofessional" or produce "shit" code.


> The greatest programming language ever is lisp. I should learn lisp.

I really should


Damnit me too


Do it, if only to find Clojure.


Clojure goes against so many of lisp's timeless philosophies and principles that it can hardly be described as a lisp.

When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche.

The best way to discover the essence of lisp is to read SICP and learn Scheme.


There it is again. Care to name any of those timeless philosophies without resorting to the minutiae of cons cells?

Clojure has very tangible and definite downsides and tradfeoffs (to name some: weaker REPL, though not as weak as some Schemes. JVM required. Heavy interop reliance), but it has served well as the flagship functional lisp.


I think there is Clojure and cloJure. The language is very different if you can mostly get by writing pure Clojure code, and another language altogether if you need to interop with Java constantly.

If you can get by mostly writing Clojure code (either by wrapping the Java libraries that you will use on helpers, or by using third-party libraries), it is a great language, even if in the end it is a very different from any other Lisp (but I'd argue that the changes are for the better, for example first instead of car, thread macros, protocols, immutable data structures). But yeah, for sure Clojure is much more optionated than any other Lisp.

Now, if you need to interop with Java code constantly, yeah, Clojure can be a pain. A good chunk of the code you will write goes to appease the alien structure that is the concept of Class on a FP language.


What principles are these?


Which of Lisp's philosophies and principles does Clojure violate?


Does XLST count then?


> 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.)

Highly recommend a journalism class at local community college.


Or just learn how to take notes. Notes should be made with the intent that someone new could understand what's going on. With that approach, if you can't make good notes, you're thinking too much about what you know and less about what others don't.


Can you elaborate on that? Why journalism in particular? Have you done this? Are you better at docs?


I studied journalism at college as part of a more general media studies course.

It does help but I am not sure I would describe _my_ education as a panacea.

The main reason it was good was because it helps frame how you think of writing,

The most important things go first. Statement of fact, then you go into what the implications are, then you start introducing less and less relevant elements.

when you’re writing you keep the 5 “W’s” in mind, make sure you answer them. (Who what where when why), for instructive documentation you add: How.

Obviously an education bakes this into you in a better way than I can convey here.

What I learned is probably only decent for writing overviews.

Personally I find structure to be the biggest bottleneck/difficulty when making documentation.

What do others normally struggle with that don’t have this education?


I recommend a class on instructions.

Learning how to write proper instructions is the gateway to proper documentation.


This is good he is not drunk enough to tell the main dark truth - there are no senior engineers, only some people who finally managed how to cope with their imposter syndrome. Oh whait...


If you keep learning and improving, imposter syndrome never goes away. After you settle in, you can get used to what you are capable of. I’ve never lost mine, it’s learn one thing, discover two more you didn’t realize were important that you don’t (yet) know, recursively


> If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

Sometimes fixing the problem will require special access to Production which you don't have, or even a specific role with that extra bit of initiative.

Otherwise i agree 100%.


If you're frequently being paged for stuff you literally can't fix, then the process/monitoring/alerting has broken down somewhere and needs to be fixed. If it can't/won't be fixed, then the company needs to hire ops people whose specific job is to react to and triage system failures -- devs should not be treated as escalation machines. If the process can't be fixed and the company won't hire people to handle the process, then you quit.


Very true. I do ops, I'm on call. Calling a developer at 3.00AM is not something I do lightly, it would have to be insanely critical.

Operation, and on-call staff fixes broken systems just enough, that they will work until 8:00AM when the developer is back at work.

Just this week I talked to a developer, and he asked if I could switch the phone numbers, so issues would get routed to him first. My question: Why? You can't really do much without me being awake as well, so maybe I get the first call, and I call you... IF I need to?


> Sometimes fixing the problem will require special access to Production which you don't have

If it's unfixable, that's when you quit


This is true unless you own a meaningful portion of the company (>1%). To dump your entire investment because of extra hours is not a way to get that asymptotic upside.

Maybe... none of this applies to people who own meaningful portions of the companies they work for.


Probably people are honest when they are drunk. There is nothing to argue with any of those comments.

But this one stood out for me!

> Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.


That's true unless you get acquired. At that point, your title is what your new overlords will use to determine your role, salary, and even whether to lay you off.


I mistakenly asked to be called the "Staff Engineer" as employee #1, I think I'm going to correct to "Principal Engineer" as soon as I can.


I've seen that happen to an excellent domain expert at a company during radical downsizing. Though TBF, that round saw fat, muscle, sinew, and bone cut.

To say nothing of a lot of brain.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: