7 ms·

Ways to annoy your senior engineer

75 points by wapasta 2y ago

TekMol 2y ago
This is what is going on in the enterprise. I wonder why I mostly see posts from people in this type of environment here on Hacker News. I would love something like Hacker News, but for indie makers, entrepreneurs and bootstrapped startups. Is there something like this?
- inciampati 2y ago
  It seems that people in these kinds of positions feel very powerless, frustrated, and cranky. And they love to vote for posts that say these kinds of things. They validate the frustration that they experience working in these enterprise environments. In theory, you're asking for hacker news, it just happens to be that there's many different communities represented here. The tyranny of the front page means you're probably missing a lot of the posts that you might want to see. And people aren't making many of those posts because they know they won't get seen by many people.
- lurking_swe 2y ago
  cynical take: those people are typically too busy working 50+ hours a week and have worse work-life-balance. they might spend less time on hacker news.
- Joel_Mckay 2y ago
  I would recommend you attend a TiE event, but mostly to listen rather than talk. It is important to understand what "investors" actually typically do, and what people say to try to convince other people their ideas are viable. https://tie.org/ https://tie.org/ It can be kind of sad to see firms at that stage, but worth learning about what other people are doing in your area. Best of luck =3
- swiftcoder 2y ago
  > This is what is going on in the enterprise This same shit also goes on at all the 10-person startups formed by former-enterprise folks, which covers a pretty big swathe of hacker news audience
lucianbr 2y ago
I wonder if anywone who could learn something from these kinds of articles ever reads them. Certainly does not feel like they do.
- edu 2y ago
  I think most of them know it , but they don’t care. They care more about pleasing execs.
sumanthvepa 2y ago
I'm the 'pointy-haired' boss and I usually don't take my engineering teams estimates at face value. I've learned to multiply the estimates to know when I can reasonably expect something to be completed. The multiplier is never less than 1.5. And I can see if they are making progress and where they might be hitting difficulties. (Most roadblocks have nothing to do with the tech. It's usually either some organisational barrier or a personal issue.)
- karparov 2y ago
  And since everybody knows that this is how management deals with estimates, there is no incentive to improve upon their own.
  - lazide 2y ago
    The big thing is usually what do various folks mean by ‘improve’? ‘As small as possible’? (Aka optimistic) ‘As accurate as possible’? (Aka as low variance) ‘As conservative as possible’? (Aka least likely to ever be exceeded) ‘As cheap to estimate as possible’? (Aka lowest overhead) Most people have no idea which strategy they are even doing.
  - sumanthvepa 2y ago
    True. But I'm not measuring their performance relative to their estimates. I'm measuring performance relative to their peers and their previous performance. So giving me a padded estimate won't make much of a difference. Obviously, judgements are deeply subjective, since no two programming tasks are ever identical or even alike, but if you code a lot like, me you have a pretty good idea of what constitutes good.
- rswail 2y ago
  "Double it and raise it to the next time unit" still works. A 1 hour job will take 2 days. A 1 day job will take 2 weeks. etc.
  - orwin 2y ago
    For me that's only true for projects/fixes with low time unit. When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself). When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.
kstrauser 2y ago
First reaction: Has this person been my coworker? I feel like someone’s been taking notes on places I’ve worked. Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never come). It’s ugly, you’re ashamed to have your name on the git blame, but your stock options went up 8% the moment you deployed to prod. The customer rarely pays you to be an artisan. They just want that feature before they write the check. I’m still highly sympathetic to the sense of pride and ownership we all want to feel over our work. That’s the best! But getting paid’s pretty cool, too. Get a hobby project you can polish into a masterpiece after work.
- dcminter 2y ago
  > OK, those ones about shifting priorities? That’s startup life. I've seen it at pretty much all scales. I think it's usually worse in bigger corps actually. Great point though - it behoves us to remember where the money for our technical airs and graces comes from.
- rswail 2y ago
  If you're following the bullshit that is SAFe/"Agile" at a startup, you're going to fail. Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.
  - inetknght 2y ago
    > GANTT charts Can you give me an estimate for these sixteen different things, and also verify which ones depend on each other?
    - hinkley 2y ago
      The Gantt is a lie to get the project approved and then beg forgiveness later. Nobody ever figures bus numbers into the chart, because it would make the timelines so much worse that management wouldn’t approve it. But the blame for going over the estimates rolls downhill. Those stupid devs can’t get anything done on time. Thankfully I haven’t had to look at one of those stupid things in about 20 years. They used to make me see red.
haburka 2y ago
I find these complaints to be symptoms of taking yourself too seriously, which is not only a poor way to act at a company but also a poor way to live your life. Yes you’re an engineer and your time is valuable but you don’t have to act like it! Even if getting distracted causes you to lose some threads, you can’t ignore that you’re helping other people in the meantime. If you’re emotionally upset when you’re helping people they’re going to feel that and not want to try their best. A company is not successful because of individuals, it’s the cooperation that causes the whole to be greater than the sum of its parts.
- gwbas1c 2y ago
  I don't think you read the article, or understand engineering if you discard the author's opinions with "taking yourself too seriously". For example, reread the following paragraph: > Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work. Again, reread it and try to understand why the author stated that, instead of accusing them of taking themselves too seriously. The problem is, if a leader asks for 3 weeks of work, and then every week asks for a different 3 weeks of work, nothing will ever get done. It belittles the engineer because that engineer isn't able to make positive contribution. I suspect that you believe that engineers are merely pawns in a political game. Ultimately, companies that operate this way fail.
  - haburka 2y ago
    Definitely I did read the article but I’ll address your point about priority shifts. I think handling priority shifts is a part of the job. If you can’t get people to talk to each other about priorities and help illuminate that they have to compromise on what is important in order to get the best outcome, then you’re failing as an engineer. However I do work at a company where I have an active hand in planning the roadmap as a senior engineer. I often tell the senior leadership what my thoughts are about priorities and I feel empowered to say “no,” or “let’s do that later” to asks. I understand this isn’t how everywhere works. Maybe the author and I have very different work experiences. To me, if someone says “we are shifting priorities.” I think of it as a chance to improve what work we are doing. I feel that the author would see it as an opportunity to waste their time more. I don’t believe that engineers are pawns in a political game. I think it’s a strange thing to suspect and I have some doubts about your mental well being. Looking through your other comments, it seems to be a common trend of yours to speak of people as pawns. Perhaps you feel like you are a pawn at work? Or maybe you see the world as a political game where you are a pawn? I don’t think that’s a wise perspective - even in chess a single pawn often can win the game. Even with even pawns, the better coordinated pawns can win. Just some food for thought.
tossandthrow 2y ago
While all these points are valid - and I for one have a couple of people to forward the article to - I think there is more to this. Alignment and understanding the product: As engineers it is easy to dismiss their task as conveying how the product works and defer to "it is implemented!". I have stup a goal to post in the non-engineering Slack channels at least a couple of times with a video of how new features work, or give a short introduction on "that new testing framework" in human language. Doing so is first and foremost a proactive move. Secondly it takes away the excuse of not knowing what eng is up to.
throw_it_now 2y ago
My pet peeve: "Could we have a meeting with your coworkers so you convince them this is the best course of action?" I'm not a salesman or an evangelist. I'm a tech person and actually the local expert in the subject, a fact that you constantly advertise to the board. If you trust me, make a decision, it's your job. Instead of that, you book the meeting, make me explain what we should do (that you vehemently agreed on before) and, when the others frown (the juniors because it's work, the seniors because it's change) you reverse the decision and quickly rebuke me and tell me we'll do it gradually (=never).
thenoblesunfish 2y ago
A really good senior engineer knows how to deliver a "quick hack" that is as well-documented and extensible as possible to avoid the most contagious tech debt. There is a big difference between "hack in production" and "suboptimal, incremental solution in production". It's very easy to see the PMs etc. as the enemy, but they would have their own list of unfair gripes about engineers (e.g. as evidenced by this article, they seem to just want to be solitary geniuses left alone to work on things they aren't communicating about).
AstroJetson 2y ago
I fixed giving “napkin” or “rough estimate” times out. I roll a D6 for number of people, D12 for number of months, D20 for the day we will go to production ( not allowed to do installation during end of month). D% is used to say how accurate the estimate is. With the requester there, I pull them out, roll them, give the estimate. I did have a VP in a meeting go “I don’t like that estimate.” I pushed the dice over and said “Ok, you roll”. Their hand got about 1/2 way before their brain caught on to what was happening and they pulled their hand back. We normally agree on them writing a 2-3 page scope and I do an estimate based off the scope. Slow learners ask, How long to get the estimate, I look them dead in the eye and reach for the dice again saying “I’d like to see the scope beforehand but ....”
- mytailorisrich 2y ago
  When I'm told "I don't like that estimate" I take it as an invitation to negotiate (same as when you don't like a quote from a tradesman) and so counter with "OK, we may be able to shave x off of it if you give us y and z in addition to what we have now or if we cut w out of the scope".
  - cbluth 2y ago
    This turns into nickel and diming, then bike shedding. For me, it's easier not to enter the process
    - hinkley 2y ago
      And then a year later I’m the only one who can remember that the reason we are in the middle of a grotesque rewrite is that we got a promise from management that we could treat all X as Y and they didn’t keep their word because that was last year and this is now. Why can’t you idiots figure out how to code? I have told a few people that when we substituted their judgment for mine this became their problem. I really think I should have said it more often.
- Xmd5a 2y ago
  I like your style https://en.wikipedia.org/wiki/The_Dice_Man https://en.wikipedia.org/wiki/The_Dice_Man >The Dice Man is a 1971 novel by American novelist George Cockcroft, writing under the pen name "Luke Rhinehart".[1] The book tells the story of a psychiatrist who makes daily decisions based on the casting of a die.[2] Cockcroft describes the origin of the title idea variously in interviews, once recalling a college "quirk" he and friends used to decide "what they were going to do that night" based on a die-roll, or sometimes to decide between mildly mischievous pranks. https://www.reddit.com/r/Teachers/comments/15c3yd4/every_year_these_kids_come_back_with_a_new/ https://www.reddit.com/r/Teachers/comments/15c3yd4/every_yea... >The newest thing here is a flock of self-proclaimed “coin boys” who carry a quarter on hand at all times and constantly flip it. They have their entire personality revolve around coins, coin flips, and chance. When we went around doing an ice breaker, 4 or 5 of the kids said some variation of “I live by the coin and die by the coin” as their fact. >Just about an hour ago, when I assigned the first assignment of the school year, one of the coin boys was bold enough to say “heads I do it, tails I don’t.” I told him if he flipped the coin he would be getting a call home on the first week of HS. He flipped it anyway and it came up heads (thank god for that at least). >But then the other coin boy in that class flipped his coin and it came up tails. He said the coin has spoken and he’s not doing it. I say very well, enjoy your 0 and your call home— what a great way to start off the school year and your high school career.
karparov 2y ago
You need to read this for a while to understand that with "engineer" they mean "programmer". Nowhere does it say "software engineer". Indicating that somebody is trying to give general advice but is actually too deep into their bubble to realize the big picture. > Engineers juggle a million things at once. Eh what? If that's how your "engineer" calendar looks like then your org has more serious problems than a spontaneous "30 min sync" popping up in your calendar. What is a "senior engineer" anyway? Everybody beyond intern stage is called "senior" these days.
- lodovic 2y ago
  There was massive inflation with job titles. When I started, we had three levels: junior, medior and senior. Anything else was just vanity. But now nobody hires medior or below anymore, so senior is the new entry level, followed by principal engineer, and "distinguished fellow engineer" is proposed as the real new senior title.
__turbobrew__ 2y ago
I just stopped going to recurring meetings with no agenda. Nothing bad has happened so far. Sometimes someone has something to discuss and asks me to show up, and then I do.
rswail 2y ago
I really really hate the use of the term "engineer" for "coder" or "programmer". All of the issues in this article are about coders that are cogs in the SAFe/Agile machines that now infest software development. NONE of them are relevant to actual engineering, software or otherwise.
- everfrustrated 2y ago
  I disagree. Engineer is correct when the role is about understanding that this is not an art [1] - there is a calculation performed to find the right balance between many variables of complexity, maintenance, cost effectiveness, ease of construction, reliability of construction, operation, etc. These apply in concept no differently to building a bridge or a distributed software system. There may be many who are just code monkeys but that doesn't mean some aren't practising engineering. [1] Art in the sense that it can be perfect in its own right. There is no perfect engineering - everything is to a requirement and result of an optimal compromise.
zmgsabst 2y ago
If you’re a senior engineer then your job is to manage these. 1 + 2: Tell them to open a ticket, mark it appropriately, and we’ll do it; but then when you come asking why we didn’t do other things, I’ll show you that chart. 4 + 4b: As a senior engineer, it’s literally your job to interface between leadership, PMs, and junior engineers. “Sync” usually means they want some time to chat about whatever comes to mind — make sure you regularly have these with all major stakeholders. Block out dedicated work hours, but let people consume your time outside of that — it’s your job. 5 + 7: Your job is to manage that we’re paid for features not craftsmanship; hacks are inevitable, but you should leave slack for improvements, document the business case for major fixes, etc. 3 + 8: Along the same lines, help leadership figure out a plan. Unavoidable thrashing happens at times at a startup, but even then, you should talk about roadmaps. Help leadership split the effort between long term goals and immediate payoffs; help them understand priorities. There are people happier remaining at career IC levels (SDE2 at Amazon) because they don’t want to do these things — and that’s perfectly okay, too.
thih9 2y ago
> [Senior engineers] keep things running, ensure projects get delivered, and prevent your codebase from turning into spaghetti. The good ones? They’re rare and highly sought after. I didn’t see much of the ”highly sought after” bit in the recent years. On the contrary, the job market looks employer-friendly and the strategies for recruiting senior engineers seem increasingly backwards. Or is it expected that good senior engineers skip recruiting and rely on networking alone?
- swiftcoder 2y ago
  > Or is it expected that good senior engineers skip recruiting and rely on networking alone? Pretty much, yeah. I don't know anyone at a senior-or-above level who spends much effort sending resumes through the front door.
- hinkley 2y ago
  We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.
  - thih9 2y ago
    In the jackass. Until now I thought I’m surrounded by people who cannot understand reasonably complex code. Currently I hope that both can be true at the same time. I’ll enjoy my job safety, although now more humbly.
    - hinkley 2y ago
      I told the last one that his confessed difficulties with documenting his code probably come not from a failure of literary skill but a failure to write code that can be explained.
      - thih9 2y ago
        That sounds like a useful distinction, I like it - thanks for sharing. I hope they draw the right conclusions, i.e. start writing code that can be explained instead of documenting current code with "# Too complex, cannot be explained"[1]. [1]: https://stackoverflow.com/a/185106 https://stackoverflow.com/a/185106
data_maan 2y ago
The points of this post are essentially how Chinese companies operate (of course , some western companies have this issue too, but for Chinese ones it seems the norm: call everyone in, waste an hour if everyone's time) :)
imiric 2y ago
All of these are familiar, unfortunately. Just one nitpick: > Proper estimations take time. IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion. Software development is inherently chaotic. Every task is different from another, and developers can only get a sense of the time and effort requirements once they start working on something. And these are constantly changing during development. It might take a long time to discover that a bug can be fixed by a single line change, or a chain of bugs might be discovered that need separate investigation, or a bug might not exist at all, etc. Every case is different. Additionally, every engineer is different, and they're different from themselves every time. Tasks that require mental effort are unpredictable by definition. Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless. They only serve to demotivate development teams when they're not met. I wish the industry would move on from them and adopt the more sensible approach of "it's done when it's done". Unfortunately, this doesn't gel with the rest of the business which functions on deadlines, so here we are.
- superfrank 2y ago
  As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years. Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless". In the places I've worked as a manager, with the managers, directors, and VPs I've worked with, I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI. Developer time is a limited and incredibly expensive resource at most companies and managers need to make sure it's used in the most impactful way that it can be. A project may make sense to do if it's going to take a month, but it may not make sense to do if it's going to take a year. Without some sort of estimate on the time a project will take, you can't properly prioritize work. There are absolutely projects where it's just like, we need to get this done no matter how long it takes, but most projects aren't like that. Again, I totally get your frustrations, but the thing I always tell my teams is let's say you wanted to build a house from scratch. You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done." I doubt you would hire them, right? You need more information than that to be able to truly make a decision because at a certain dollar value it's just not worth it anymore. You don't need an exact dollar amount, but knowing whether it's going to cost $100k or $500k will completely change the value proposition. Again, I totally feel where you're coming from with pushing back on estimates, but I don't think you're ever going to get away from them. With that in mind, one of the things I've started asking my teams to do where they're really pushing back on estimating is to take a day and think on it and then come back and give me two numbers. Give me an estimate that you're 90% sure is too high and a second estimate that you're 90% sure is too low. I've feel like that takes some of the pressure off because there's no exact number that they can be held to and it gives me enough info to make a decision.
procaryote 2y ago
Estimating is useful for: * getting an idea if something is worth doing * picking between things that are equally valuable but may be differently expensive * rejecting things that are estimated to take months, as that means we have no idea and need to break it down more * making the scope more explicit Estimating is not useful for: * planning a release date for the thing you haven't started yet
brookst 2y ago
Those sound like very disruptive and bad for everyone ways to annoy a senior engineer. As a lifelong prodigy manager I much prefer stuff like “here’s the spec, how long do you think it will take to type the code in”.
egeozcan 2y ago
The only correct estimation is actually doing the work and looking at how long it took. The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are usually named "concepts". For bugs: Half the amount of time needed for the feature that caused that bug. They need a workaround? It will actually take longer - except when the workaround is already available and just needs to be applied. Then it's 90% of the proper solution.
- swiftcoder 2y ago
  > The only correct estimation is actually doing the work and looking at how long it took. You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely. If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...
  - egeozcan 2y ago
    I don't think you are contradicting me, but I'm not really sure.
  - bonesss 2y ago
    Yeah, the general attitude that estimation is impossible, guesswork, or useless is simply not commercially or professionally defensible. Other fields do it all the time without our tools, competencies, supposed specialties, or environmental control. If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience. Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.
thecleaner 2y ago
I like t-shirt estimates but only when we all agree we known wtf we are talking about. I also really like hacks. They get the job done and not everything needs layers and layers of leaky abstraction. I also quite like easy things like Config fixes, esp if they get escalated. You can leverage these to show impact and get a good rapport going. I hate meetings without agenda. Honestly send me a message and I'll make sure I reply. Meetings with written agenda are great.
tgv 2y ago
I know it is quite common, but the culture is the problem. The "leadership" in this piece have interests that are almost orthogonal to that of the engineer. The company is structured top-down, leading to a "it must become true because I said so" mentality, and probably the incentives of the people involved don't align either. Management doesn't have to care about that, because they're not incentivized to. When the wrong people get into that chain, these things happen. And worse too: in other industries, managers regularly override safety concerns.
sneak 2y ago
A lot of these are simply because most managers type badly or slowly. They’d rather speak than type.
ChrisMarshallNY 2y ago
#3 is the biggie, for me (quick estimate). I used to work for a Japanese corporation, and, when meeting with Japanese managers, you’ll see that they have a small notebook, open on the table, in front of them. Occasionally, they will jot something down in it. You will also note that, whenever a date is mentioned, something gets written. You are now being held to that date. They will completely leave you alone, until that date, when they will expect you to deliver “what was promised.” In my experience, Americans never took this seriously, and it could be a real problem.
mythrwy 2y ago
I have this recurring thought that every task I do seems to take either 10 minutes or 3 days and I never really know which it will beforehand. Of course that's an exaggeration, but I've always found software time estimation to be difficult compared to actually writing the software and usually not very accurate.
gwbas1c 2y ago
The author seems to work for a company where engineers are treated as pawns in political games; and where leadership is more about perception than accomplishment. The best way to handle situations like this is to leave, quickly! Companies that operate like this don't last long, because someone else will come and out compete them. Edit: One thing I do when interviewing, is when I talk to the manager, I point blank ask, "how often will I be asked to change a task before I complete it?," and, " how many meetings will I attend during a day?." It screens out situations like this very quickly, because the managers who are looking to hire pawns won't hire me after asking questions like that.
- imiric 2y ago
  > The best way to handle situations like this is to leave, quickly! If you find these situations frustrating, I agree. There is little hope of changing how software development is done in these companies. > Companies that operate like this don't last long, because someone else will come and out compete them. I take it that you haven't worked in many corporate environments. This is how software development is done in many, if not most, large companies. Their only competition are other companies with the same processes. Smaller companies can operate more quickly, and sometimes this can be a variable that helps with disrupting established behemoths, but it's usually not the primary one, and it takes many years to do so.
  - gwbas1c 2y ago
    > I take it that you haven't worked in many corporate environments. I'm mid-career and I have worked in all different sized companies. That's why I explained how to avoid these situations. You don't have to put up with being a pawn, nor should you encourage others to put up with working conditions like this. Edit: I was in situations like the article describes twice. The first time was when I tried to start a company. It took me over a year to realize the guy I was working with was just an "idea person," who couldn't stop letting his imagination run away. We could never work on a hypothesis, because every other week he had a new idea and wouldn't follow through on last week's idea. The other time was a startup where I built an industry-leading product. It was usually middle management and inexperienced people who acted like the article described. Upper management would intervene, and often people who acted like the article described got pushed out of the company.
physicsguy 2y ago
8 is the worst. In my last company there was a new top priority every two weeks. And i still had a very junior team who needed a ton of mentoring and development to be able to turn things around quickly. Who were then getting blamed for not hitting impossible-in-the-first-place deadlines.
graynk 2y ago
The post and most of the comments feel kind of naive. Yes, these things are frustrating, but it’s your job. That’s what you’re paid to do. Nobody cares if you ship a hack if it “works”. Every single legacy project I’ve seen that earns actual money is full of hacks like that - it’s just the way it is, and a senior engineer should know how to work with that, how to communicate what really needs to be done and why it’s important. That involves dealing with management that doesn’t speak your language - learn how to do that too.

75 points by wapasta 2y ago

This is what is going on in the enterprise. I wonder why I mostly see posts from people in this type of environment here on Hacker News. I would love something like Hacker News, but for indie makers, entrepreneurs and bootstrapped startups. Is there something like this?

inciampati 2y ago
It seems that people in these kinds of positions feel very powerless, frustrated, and cranky. And they love to vote for posts that say these kinds of things. They validate the frustration that they experience working in these enterprise environments. In theory, you're asking for hacker news, it just happens to be that there's many different communities represented here. The tyranny of the front page means you're probably missing a lot of the posts that you might want to see. And people aren't making many of those posts because they know they won't get seen by many people.
lurking_swe 2y ago
cynical take: those people are typically too busy working 50+ hours a week and have worse work-life-balance. they might spend less time on hacker news.
Joel_Mckay 2y ago
I would recommend you attend a TiE event, but mostly to listen rather than talk. It is important to understand what "investors" actually typically do, and what people say to try to convince other people their ideas are viable. https://tie.org/ https://tie.org/ It can be kind of sad to see firms at that stage, but worth learning about what other people are doing in your area. Best of luck =3
swiftcoder 2y ago
> This is what is going on in the enterprise This same shit also goes on at all the 10-person startups formed by former-enterprise folks, which covers a pretty big swathe of hacker news audience

lucianbr 2y ago

I wonder if anywone who could learn something from these kinds of articles ever reads them. Certainly does not feel like they do.

edu 2y ago
I think most of them know it , but they don’t care. They care more about pleasing execs.

sumanthvepa 2y ago

I'm the 'pointy-haired' boss and I usually don't take my engineering teams estimates at face value. I've learned to multiply the estimates to know when I can reasonably expect something to be completed. The multiplier is never less than 1.5. And I can see if they are making progress and where they might be hitting difficulties. (Most roadblocks have nothing to do with the tech. It's usually either some organisational barrier or a personal issue.)

karparov 2y ago
And since everybody knows that this is how management deals with estimates, there is no incentive to improve upon their own.
- lazide 2y ago
  The big thing is usually what do various folks mean by ‘improve’? ‘As small as possible’? (Aka optimistic) ‘As accurate as possible’? (Aka as low variance) ‘As conservative as possible’? (Aka least likely to ever be exceeded) ‘As cheap to estimate as possible’? (Aka lowest overhead) Most people have no idea which strategy they are even doing.
- sumanthvepa 2y ago
  True. But I'm not measuring their performance relative to their estimates. I'm measuring performance relative to their peers and their previous performance. So giving me a padded estimate won't make much of a difference. Obviously, judgements are deeply subjective, since no two programming tasks are ever identical or even alike, but if you code a lot like, me you have a pretty good idea of what constitutes good.
rswail 2y ago
"Double it and raise it to the next time unit" still works. A 1 hour job will take 2 days. A 1 day job will take 2 weeks. etc.
- orwin 2y ago
  For me that's only true for projects/fixes with low time unit. When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself). When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.

kstrauser 2y ago

First reaction: Has this person been my coworker? I feel like someone’s been taking notes on places I’ve worked. Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never come). It’s ugly, you’re ashamed to have your name on the git blame, but your stock options went up 8% the moment you deployed to prod. The customer rarely pays you to be an artisan. They just want that feature before they write the check. I’m still highly sympathetic to the sense of pride and ownership we all want to feel over our work. That’s the best! But getting paid’s pretty cool, too. Get a hobby project you can polish into a masterpiece after work.

dcminter 2y ago
> OK, those ones about shifting priorities? That’s startup life. I've seen it at pretty much all scales. I think it's usually worse in bigger corps actually. Great point though - it behoves us to remember where the money for our technical airs and graces comes from.
rswail 2y ago
If you're following the bullshit that is SAFe/"Agile" at a startup, you're going to fail. Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.
- inetknght 2y ago
  > GANTT charts Can you give me an estimate for these sixteen different things, and also verify which ones depend on each other?
  - hinkley 2y ago
    The Gantt is a lie to get the project approved and then beg forgiveness later. Nobody ever figures bus numbers into the chart, because it would make the timelines so much worse that management wouldn’t approve it. But the blame for going over the estimates rolls downhill. Those stupid devs can’t get anything done on time. Thankfully I haven’t had to look at one of those stupid things in about 20 years. They used to make me see red.

haburka 2y ago

I find these complaints to be symptoms of taking yourself too seriously, which is not only a poor way to act at a company but also a poor way to live your life. Yes you’re an engineer and your time is valuable but you don’t have to act like it! Even if getting distracted causes you to lose some threads, you can’t ignore that you’re helping other people in the meantime. If you’re emotionally upset when you’re helping people they’re going to feel that and not want to try their best. A company is not successful because of individuals, it’s the cooperation that causes the whole to be greater than the sum of its parts.

gwbas1c 2y ago
I don't think you read the article, or understand engineering if you discard the author's opinions with "taking yourself too seriously". For example, reread the following paragraph: > Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work. Again, reread it and try to understand why the author stated that, instead of accusing them of taking themselves too seriously. The problem is, if a leader asks for 3 weeks of work, and then every week asks for a different 3 weeks of work, nothing will ever get done. It belittles the engineer because that engineer isn't able to make positive contribution. I suspect that you believe that engineers are merely pawns in a political game. Ultimately, companies that operate this way fail.
- haburka 2y ago
  Definitely I did read the article but I’ll address your point about priority shifts. I think handling priority shifts is a part of the job. If you can’t get people to talk to each other about priorities and help illuminate that they have to compromise on what is important in order to get the best outcome, then you’re failing as an engineer. However I do work at a company where I have an active hand in planning the roadmap as a senior engineer. I often tell the senior leadership what my thoughts are about priorities and I feel empowered to say “no,” or “let’s do that later” to asks. I understand this isn’t how everywhere works. Maybe the author and I have very different work experiences. To me, if someone says “we are shifting priorities.” I think of it as a chance to improve what work we are doing. I feel that the author would see it as an opportunity to waste their time more. I don’t believe that engineers are pawns in a political game. I think it’s a strange thing to suspect and I have some doubts about your mental well being. Looking through your other comments, it seems to be a common trend of yours to speak of people as pawns. Perhaps you feel like you are a pawn at work? Or maybe you see the world as a political game where you are a pawn? I don’t think that’s a wise perspective - even in chess a single pawn often can win the game. Even with even pawns, the better coordinated pawns can win. Just some food for thought.

tossandthrow 2y ago

While all these points are valid - and I for one have a couple of people to forward the article to - I think there is more to this. Alignment and understanding the product: As engineers it is easy to dismiss their task as conveying how the product works and defer to "it is implemented!". I have stup a goal to post in the non-engineering Slack channels at least a couple of times with a video of how new features work, or give a short introduction on "that new testing framework" in human language. Doing so is first and foremost a proactive move. Secondly it takes away the excuse of not knowing what eng is up to.

throw_it_now 2y ago

My pet peeve: "Could we have a meeting with your coworkers so you convince them this is the best course of action?" I'm not a salesman or an evangelist. I'm a tech person and actually the local expert in the subject, a fact that you constantly advertise to the board. If you trust me, make a decision, it's your job. Instead of that, you book the meeting, make me explain what we should do (that you vehemently agreed on before) and, when the others frown (the juniors because it's work, the seniors because it's change) you reverse the decision and quickly rebuke me and tell me we'll do it gradually (=never).

thenoblesunfish 2y ago

A really good senior engineer knows how to deliver a "quick hack" that is as well-documented and extensible as possible to avoid the most contagious tech debt. There is a big difference between "hack in production" and "suboptimal, incremental solution in production". It's very easy to see the PMs etc. as the enemy, but they would have their own list of unfair gripes about engineers (e.g. as evidenced by this article, they seem to just want to be solitary geniuses left alone to work on things they aren't communicating about).

AstroJetson 2y ago

I fixed giving “napkin” or “rough estimate” times out. I roll a D6 for number of people, D12 for number of months, D20 for the day we will go to production ( not allowed to do installation during end of month). D% is used to say how accurate the estimate is. With the requester there, I pull them out, roll them, give the estimate. I did have a VP in a meeting go “I don’t like that estimate.” I pushed the dice over and said “Ok, you roll”. Their hand got about 1/2 way before their brain caught on to what was happening and they pulled their hand back. We normally agree on them writing a 2-3 page scope and I do an estimate based off the scope. Slow learners ask, How long to get the estimate, I look them dead in the eye and reach for the dice again saying “I’d like to see the scope beforehand but ....”

mytailorisrich 2y ago
When I'm told "I don't like that estimate" I take it as an invitation to negotiate (same as when you don't like a quote from a tradesman) and so counter with "OK, we may be able to shave x off of it if you give us y and z in addition to what we have now or if we cut w out of the scope".
- cbluth 2y ago
  This turns into nickel and diming, then bike shedding. For me, it's easier not to enter the process
  - hinkley 2y ago
    And then a year later I’m the only one who can remember that the reason we are in the middle of a grotesque rewrite is that we got a promise from management that we could treat all X as Y and they didn’t keep their word because that was last year and this is now. Why can’t you idiots figure out how to code? I have told a few people that when we substituted their judgment for mine this became their problem. I really think I should have said it more often.
Xmd5a 2y ago
I like your style https://en.wikipedia.org/wiki/The_Dice_Man https://en.wikipedia.org/wiki/The_Dice_Man >The Dice Man is a 1971 novel by American novelist George Cockcroft, writing under the pen name "Luke Rhinehart".[1] The book tells the story of a psychiatrist who makes daily decisions based on the casting of a die.[2] Cockcroft describes the origin of the title idea variously in interviews, once recalling a college "quirk" he and friends used to decide "what they were going to do that night" based on a die-roll, or sometimes to decide between mildly mischievous pranks. https://www.reddit.com/r/Teachers/comments/15c3yd4/every_year_these_kids_come_back_with_a_new/ https://www.reddit.com/r/Teachers/comments/15c3yd4/every_yea... >The newest thing here is a flock of self-proclaimed “coin boys” who carry a quarter on hand at all times and constantly flip it. They have their entire personality revolve around coins, coin flips, and chance. When we went around doing an ice breaker, 4 or 5 of the kids said some variation of “I live by the coin and die by the coin” as their fact. >Just about an hour ago, when I assigned the first assignment of the school year, one of the coin boys was bold enough to say “heads I do it, tails I don’t.” I told him if he flipped the coin he would be getting a call home on the first week of HS. He flipped it anyway and it came up heads (thank god for that at least). >But then the other coin boy in that class flipped his coin and it came up tails. He said the coin has spoken and he’s not doing it. I say very well, enjoy your 0 and your call home— what a great way to start off the school year and your high school career.

karparov 2y ago

You need to read this for a while to understand that with "engineer" they mean "programmer". Nowhere does it say "software engineer". Indicating that somebody is trying to give general advice but is actually too deep into their bubble to realize the big picture. > Engineers juggle a million things at once. Eh what? If that's how your "engineer" calendar looks like then your org has more serious problems than a spontaneous "30 min sync" popping up in your calendar. What is a "senior engineer" anyway? Everybody beyond intern stage is called "senior" these days.

lodovic 2y ago
There was massive inflation with job titles. When I started, we had three levels: junior, medior and senior. Anything else was just vanity. But now nobody hires medior or below anymore, so senior is the new entry level, followed by principal engineer, and "distinguished fellow engineer" is proposed as the real new senior title.

__turbobrew__ 2y ago

I just stopped going to recurring meetings with no agenda. Nothing bad has happened so far. Sometimes someone has something to discuss and asks me to show up, and then I do.

rswail 2y ago

I really really hate the use of the term "engineer" for "coder" or "programmer". All of the issues in this article are about coders that are cogs in the SAFe/Agile machines that now infest software development. NONE of them are relevant to actual engineering, software or otherwise.

everfrustrated 2y ago
I disagree. Engineer is correct when the role is about understanding that this is not an art [1] - there is a calculation performed to find the right balance between many variables of complexity, maintenance, cost effectiveness, ease of construction, reliability of construction, operation, etc. These apply in concept no differently to building a bridge or a distributed software system. There may be many who are just code monkeys but that doesn't mean some aren't practising engineering. [1] Art in the sense that it can be perfect in its own right. There is no perfect engineering - everything is to a requirement and result of an optimal compromise.

zmgsabst 2y ago

If you’re a senior engineer then your job is to manage these. 1 + 2: Tell them to open a ticket, mark it appropriately, and we’ll do it; but then when you come asking why we didn’t do other things, I’ll show you that chart. 4 + 4b: As a senior engineer, it’s literally your job to interface between leadership, PMs, and junior engineers. “Sync” usually means they want some time to chat about whatever comes to mind — make sure you regularly have these with all major stakeholders. Block out dedicated work hours, but let people consume your time outside of that — it’s your job. 5 + 7: Your job is to manage that we’re paid for features not craftsmanship; hacks are inevitable, but you should leave slack for improvements, document the business case for major fixes, etc. 3 + 8: Along the same lines, help leadership figure out a plan. Unavoidable thrashing happens at times at a startup, but even then, you should talk about roadmaps. Help leadership split the effort between long term goals and immediate payoffs; help them understand priorities. There are people happier remaining at career IC levels (SDE2 at Amazon) because they don’t want to do these things — and that’s perfectly okay, too.

thih9 2y ago

> [Senior engineers] keep things running, ensure projects get delivered, and prevent your codebase from turning into spaghetti. The good ones? They’re rare and highly sought after. I didn’t see much of the ”highly sought after” bit in the recent years. On the contrary, the job market looks employer-friendly and the strategies for recruiting senior engineers seem increasingly backwards. Or is it expected that good senior engineers skip recruiting and rely on networking alone?

swiftcoder 2y ago
> Or is it expected that good senior engineers skip recruiting and rely on networking alone? Pretty much, yeah. I don't know anyone at a senior-or-above level who spends much effort sending resumes through the front door.
hinkley 2y ago
We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.
- thih9 2y ago
  In the jackass. Until now I thought I’m surrounded by people who cannot understand reasonably complex code. Currently I hope that both can be true at the same time. I’ll enjoy my job safety, although now more humbly.
  - hinkley 2y ago
    I told the last one that his confessed difficulties with documenting his code probably come not from a failure of literary skill but a failure to write code that can be explained.
    - thih9 2y ago
      That sounds like a useful distinction, I like it - thanks for sharing. I hope they draw the right conclusions, i.e. start writing code that can be explained instead of documenting current code with "# Too complex, cannot be explained"[1]. [1]: https://stackoverflow.com/a/185106 https://stackoverflow.com/a/185106

data_maan 2y ago

The points of this post are essentially how Chinese companies operate (of course , some western companies have this issue too, but for Chinese ones it seems the norm: call everyone in, waste an hour if everyone's time) :)

imiric 2y ago

All of these are familiar, unfortunately. Just one nitpick: > Proper estimations take time. IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion. Software development is inherently chaotic. Every task is different from another, and developers can only get a sense of the time and effort requirements once they start working on something. And these are constantly changing during development. It might take a long time to discover that a bug can be fixed by a single line change, or a chain of bugs might be discovered that need separate investigation, or a bug might not exist at all, etc. Every case is different. Additionally, every engineer is different, and they're different from themselves every time. Tasks that require mental effort are unpredictable by definition. Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless. They only serve to demotivate development teams when they're not met. I wish the industry would move on from them and adopt the more sensible approach of "it's done when it's done". Unfortunately, this doesn't gel with the rest of the business which functions on deadlines, so here we are.

superfrank 2y ago
As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years. Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless". In the places I've worked as a manager, with the managers, directors, and VPs I've worked with, I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI. Developer time is a limited and incredibly expensive resource at most companies and managers need to make sure it's used in the most impactful way that it can be. A project may make sense to do if it's going to take a month, but it may not make sense to do if it's going to take a year. Without some sort of estimate on the time a project will take, you can't properly prioritize work. There are absolutely projects where it's just like, we need to get this done no matter how long it takes, but most projects aren't like that. Again, I totally get your frustrations, but the thing I always tell my teams is let's say you wanted to build a house from scratch. You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done." I doubt you would hire them, right? You need more information than that to be able to truly make a decision because at a certain dollar value it's just not worth it anymore. You don't need an exact dollar amount, but knowing whether it's going to cost $100k or $500k will completely change the value proposition. Again, I totally feel where you're coming from with pushing back on estimates, but I don't think you're ever going to get away from them. With that in mind, one of the things I've started asking my teams to do where they're really pushing back on estimating is to take a day and think on it and then come back and give me two numbers. Give me an estimate that you're 90% sure is too high and a second estimate that you're 90% sure is too low. I've feel like that takes some of the pressure off because there's no exact number that they can be held to and it gives me enough info to make a decision.

procaryote 2y ago

Estimating is useful for: * getting an idea if something is worth doing * picking between things that are equally valuable but may be differently expensive * rejecting things that are estimated to take months, as that means we have no idea and need to break it down more * making the scope more explicit Estimating is not useful for: * planning a release date for the thing you haven't started yet

brookst 2y ago

Those sound like very disruptive and bad for everyone ways to annoy a senior engineer. As a lifelong prodigy manager I much prefer stuff like “here’s the spec, how long do you think it will take to type the code in”.

egeozcan 2y ago

The only correct estimation is actually doing the work and looking at how long it took. The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are usually named "concepts". For bugs: Half the amount of time needed for the feature that caused that bug. They need a workaround? It will actually take longer - except when the workaround is already available and just needs to be applied. Then it's 90% of the proper solution.

swiftcoder 2y ago
> The only correct estimation is actually doing the work and looking at how long it took. You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely. If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...
- egeozcan 2y ago
  I don't think you are contradicting me, but I'm not really sure.
- bonesss 2y ago
  Yeah, the general attitude that estimation is impossible, guesswork, or useless is simply not commercially or professionally defensible. Other fields do it all the time without our tools, competencies, supposed specialties, or environmental control. If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience. Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.

thecleaner 2y ago

I like t-shirt estimates but only when we all agree we known wtf we are talking about. I also really like hacks. They get the job done and not everything needs layers and layers of leaky abstraction. I also quite like easy things like Config fixes, esp if they get escalated. You can leverage these to show impact and get a good rapport going. I hate meetings without agenda. Honestly send me a message and I'll make sure I reply. Meetings with written agenda are great.

tgv 2y ago

I know it is quite common, but the culture is the problem. The "leadership" in this piece have interests that are almost orthogonal to that of the engineer. The company is structured top-down, leading to a "it must become true because I said so" mentality, and probably the incentives of the people involved don't align either. Management doesn't have to care about that, because they're not incentivized to. When the wrong people get into that chain, these things happen. And worse too: in other industries, managers regularly override safety concerns.

sneak 2y ago

A lot of these are simply because most managers type badly or slowly. They’d rather speak than type.

ChrisMarshallNY 2y ago

#3 is the biggie, for me (quick estimate). I used to work for a Japanese corporation, and, when meeting with Japanese managers, you’ll see that they have a small notebook, open on the table, in front of them. Occasionally, they will jot something down in it. You will also note that, whenever a date is mentioned, something gets written. You are now being held to that date. They will completely leave you alone, until that date, when they will expect you to deliver “what was promised.” In my experience, Americans never took this seriously, and it could be a real problem.

mythrwy 2y ago

I have this recurring thought that every task I do seems to take either 10 minutes or 3 days and I never really know which it will beforehand. Of course that's an exaggeration, but I've always found software time estimation to be difficult compared to actually writing the software and usually not very accurate.

gwbas1c 2y ago

The author seems to work for a company where engineers are treated as pawns in political games; and where leadership is more about perception than accomplishment. The best way to handle situations like this is to leave, quickly! Companies that operate like this don't last long, because someone else will come and out compete them. Edit: One thing I do when interviewing, is when I talk to the manager, I point blank ask, "how often will I be asked to change a task before I complete it?," and, " how many meetings will I attend during a day?." It screens out situations like this very quickly, because the managers who are looking to hire pawns won't hire me after asking questions like that.

imiric 2y ago
> The best way to handle situations like this is to leave, quickly! If you find these situations frustrating, I agree. There is little hope of changing how software development is done in these companies. > Companies that operate like this don't last long, because someone else will come and out compete them. I take it that you haven't worked in many corporate environments. This is how software development is done in many, if not most, large companies. Their only competition are other companies with the same processes. Smaller companies can operate more quickly, and sometimes this can be a variable that helps with disrupting established behemoths, but it's usually not the primary one, and it takes many years to do so.
- gwbas1c 2y ago
  > I take it that you haven't worked in many corporate environments. I'm mid-career and I have worked in all different sized companies. That's why I explained how to avoid these situations. You don't have to put up with being a pawn, nor should you encourage others to put up with working conditions like this. Edit: I was in situations like the article describes twice. The first time was when I tried to start a company. It took me over a year to realize the guy I was working with was just an "idea person," who couldn't stop letting his imagination run away. We could never work on a hypothesis, because every other week he had a new idea and wouldn't follow through on last week's idea. The other time was a startup where I built an industry-leading product. It was usually middle management and inexperienced people who acted like the article described. Upper management would intervene, and often people who acted like the article described got pushed out of the company.

physicsguy 2y ago

8 is the worst. In my last company there was a new top priority every two weeks. And i still had a very junior team who needed a ton of mentoring and development to be able to turn things around quickly. Who were then getting blamed for not hitting impossible-in-the-first-place deadlines.

graynk 2y ago

The post and most of the comments feel kind of naive. Yes, these things are frustrating, but it’s your job. That’s what you’re paid to do. Nobody cares if you ship a hack if it “works”. Every single legacy project I’ve seen that earns actual money is full of hacks like that - it’s just the way it is, and a senior engineer should know how to work with that, how to communicate what really needs to be done and why it’s important. That involves dealing with management that doesn’t speak your language - learn how to do that too.