[HN Gopher] Hard-to-swallow truths they won't tell you about sof...
___________________________________________________________________
Hard-to-swallow truths they won't tell you about software engineer
job
Author : thunderbong
Score : 670 points
Date : 2023-11-08 10:41 UTC (12 hours ago)
(HTM) web link (www.mensurdurakovic.com)
(TXT) w3m dump (www.mensurdurakovic.com)
| konschubert wrote:
| Meh. It's not that bad. Legacy codebases can be fun. If you have
| a good team, your meetings will be meaningful or you will cut
| them.
| shmde wrote:
| > Legacy codebases can be fun.
|
| "Legacy codebases" and "fun" should not appear in the same
| sentence.
| wrzuteczka wrote:
| Discovering how a large system works can be fun. Even if a
| codebase is old, but the design is good, it can be
| gratifying.
| wkjagt wrote:
| I've always liked working in legacy code bases. It's like doing
| archeology. Seemingly bad code maybe didn't start out as bad
| code, but was made bad over time because of historical reasons
| (last minute product changes, time pressure, local changes
| without understanding the bigger picture). It can be very
| rewarding to make sense of it. And it makes you realize that
| any code you write yourself will be legacy code soon too, and
| someone else will need to be able to make sense of it again.
| supriyo-biswas wrote:
| It depends.
|
| The thing about inheriting an older, undocumented codebase is
| that it often blows up in ways that you least expect; even
| drawing assumptions about how a function works based on its
| name can be problematic.
| Tainnor wrote:
| Or when you remove some "unused" code, only to find out
| that it was somehow used by reflection and your IDE can't
| even figure that out because the framework you're using was
| discontinued in 2010. Also of course, there's no test for
| that.
| konschubert wrote:
| Sometimes bad develops wrote bad code, but with a good team,
| you can do a fun cleanup!
|
| It's all about the team.
| kagakuninja wrote:
| I've worked on plenty of legacy code over 37 years. It all
| depends on the management environment and how bad the code
| is. Sometimes legacy code is like being mired in quicksand.
| toast0 wrote:
| Legacy in business just means it's a real product/process that
| has customers and/or makes an important output.
|
| Otherwise, if people didn't like it for whatever reason, they
| could just stop doing it.
|
| It's great to be working on something that's useful and
| important.
| Tao3300 wrote:
| Yeah, a lot of greenfield projects fail, and the road to that
| failure is fraught with pain and burnout.
|
| Cities are legacy projects, colonies are greenfield. Both
| have their pros and cons.
| Ocerge wrote:
| I've grown to appreciate legacy code more than greenfield. It's
| real code that makes money (hopefully) and solves problems.
| Code is bad? Well, it's probably for good reason as real-world
| problems are messy. Also a lot less analysis by paralysis.
| atleastoptimal wrote:
| The rate at which this stuff happens is proportional to the
| average age of employees at the company
| nik736 wrote:
| This is exactly what I noticed as well.
| ilikerashers wrote:
| I always refer to this paper when I think about advising
| graduates: https://blog.pragmaticengineer.com/software-
| engineering-sala...
|
| There are different problems in different orgs with different
| value adds. You can be super busy firefighting for a company that
| doesn't value your work or calm, well-paid but unchallenged in
| another.
|
| Also the same general pattern of learn -> earn -> own applies in
| tech. Learn your trade, milk it for a number of years to setup
| your life, own your own consultancy/company.
| yodsanklai wrote:
| Some truth but this seriously lacks nuance. Not all colleges or
| companies are equal.
| osullip wrote:
| Overall, I think this article is good.
|
| I've been in the game a long time and there is not much here I
| would disagree with.
|
| "Working in software engineering often means long working hours.
| Most of the time, you are glued to a computer screen, with little
| work-life balance."
|
| For sure this is true. The younger you are, the easier it is to
| deal with and be amazingly productive. As you get older, life
| creeps back in and you get a bit of balance.
|
| When you get to my age it becomes less about screentime and more
| about problem solving. Something I am very happy about.
|
| As a career, it's 8 out of 10.
| gipp wrote:
| Eh that's one of the least universal ones in there. I've worked
| in tech for a decade now across 6 positions in 4 companies and
| I have never had any complaints about WLB. If anything, I
| frequently feel like I'm getting away with something when it
| comes to how little I can actually get by with doing if I want
| to.
| donatj wrote:
| > College will not prepare you for the job
|
| I'm on the fence. Not initially, sure. But there are embedded
| lessons that click later.
|
| I was ten years into my career before I needed to write a b-tree
| or a double ended linked list, but when the need arose I was very
| grateful for having the ability to recognize it, and the
| familiarity to act on it.
|
| Some things I learned such as the wonderful value of pure
| functions just didn't click for about as long. I'd done a ton of
| Scheme in College and at the time it was nothing but a
| frustration "Just let me mutate state, this is dumb" it wasn't
| until I had years of tracking down what the heck was mutating
| state in a giant old code base that I learned to appreciate
| functional programming.
| Manfred wrote:
| It's also very valuable to have a shared frame of reference
| with colleagues so you can communicate more efficiently. Saying
| things like "this is like backpressure" instead of having to
| explain the entire concept is very valuable.
| throw555chip wrote:
| I'm not degreed, been working with and for PhD's, people with
| and without degrees for 3 decades including several stints at
| valley startups and never heard anyone use the term
| backpressure outside of a mechanical engineering context.
| Manfred wrote:
| It's a term in queuing theory:
| https://en.wikipedia.org/wiki/Backpressure_routing
| mordae wrote:
| Do you need college for that, though? I don't have one and
| still know how to implement a double-linked list, trees, tries,
| hash maps and what to test for when implementing binary
| search[^1]. Just keep your eyes open.
|
| [^1]: https://blog.research.google/2006/06/extra-extra-read-
| all-ab...
|
| If anything, I miss the linear algebra drills the most.
| sarchertech wrote:
| I was a self taught programmer for close to a decade before
| going back for a degree and I've been working for almost a
| decade since finishing.
|
| Unlike self teaching, a degree forces you to learn the boring
| bits as well as the interesting stuff. When I was self
| taught, I'd flitter around and pick up fun pieces here and
| there, but with no real focus.
|
| Some people are disciplined enough to teach themselves the
| equivalent of a 4 year CS degree. Most are not.
|
| And there are people I've worked with, without degrees who
| are far better programmers than I am. But they still tended
| to have some gaps. I'm fairly certain they'd be even better
| with a degree.
| dvngnt_ wrote:
| if you learn the same material, then obviously no. there are
| open source cs degrees and by nature everything is accessible
| online.
|
| but you're almost guaranteed to encounter DS&A courses in
| college which gives you a base level of understanding.
|
| someone self-taught might not.
| Clubber wrote:
| >I'm on the fence. Not initially, sure. But there are embedded
| lessons that click later.
|
| College can give you a great baseline to build upon. I can't
| tell you the number of developers with 10 years experience and
| a degree that I've interviewed who could't explain what
| database normalization was.
|
| Having said that, the vast, vast, vast majority of stuff I know
| I learned "on the streets."
| makeitdouble wrote:
| I can't remember what I did in CS in college. College was fun
| and there was a ton of interesting stuff in general, but that's
| just 1 or 2 years worth of learning compared to working full
| time for a decade or more after that.
|
| Even on the purely theoretical side I think I learned BNF or
| design patterns on the job. Same for algorithms, you'll see a
| lot more going through react's inner workings than sitting in
| CS courses.
| mettamage wrote:
| The best college courses taught me more than my jobs ever did.
| Creating my own iPhone app and reimplementing rowhammer stand
| out. The app I sold and reimplementing rowhammer required me to
| learn about C, assembly and CPU architecture _fast_. It gave me
| a mindset that still serves me. And sometimes it allows me to
| pentest my employer because I smell a vulnerability.
|
| The average college course, yea not great...
| stackedinserter wrote:
| OTOH you don't need 5 years and $50K debt to learn these
| basics.
| franze wrote:
| You do not create clean code for others, you create it for your
| future self. And he/she will appreciate it.
| 0xfab1 wrote:
| Future maintainers, who could be you. It has happened to me a
| few times, and I thanked my past self every time.
|
| It doesn't even have to be clean code. Sometimes I'll even
| settle for understandable code. In my experience, however, few
| people care about this. My most common comment in code review
| is "add doc" or "add explanation"
| m000 wrote:
| True. But you should also write it for your fellow
| developers/engineers. If the culture among engineers in your
| job discounts the value of clean code, you're probably entering
| a world of pain.
|
| Sure, you should not obsess over clean code, as it does not
| _directly_ produce value. You should also not expect _your
| manager_ to understand its value. But if your fellow engineers
| frown upon efforts to improve code quality, start looking for
| your next job. The mental drain is just not worth it.
|
| Esentially, where the clean code is appreciated, mediocre
| engineers/developers will eventualy acquire "guru" status, just
| because they happened to be hired a year or two earlier than
| the better ones. And will often be unfriendly to anyone
| "threatening" their status.
| Gazoo101 wrote:
| Without knowing the exact expectations of the people the author
| spoke to, I'd imagine lots of the misconceptions are on-point.
|
| One personal exception for me was how university (not college)
| prepared me for my future in software engineering. The courses I
| took quite often involved group projects of 2-3 people completing
| work cooperatively. Undoubtedly this was - by far - one of the
| best and closest to real-work experiences I had during my earlier
| education.
|
| Compromise, discussion, division of labor, and a healthy bit of
| experience with individuals who'd prefer to be part of the
| project credits but ideally do as little of the work as possible.
| fjfaase wrote:
| After being a software engineer for over 30 year, I agree with
| all the points. I have come to the conclusion that being a
| software engineer is one of the hardest jobs. Also because your
| often confronted with your weaknesses. But that also gives you
| room to grow. I also have come to realize that being a software
| engineer, changes how you view the world, because it forces you
| to think deeper about problems. The problems behind the problems.
| In sense that alienates you from all those people who do not have
| to deal with hard problems, are not used to think deeply about
| problems. And there are a lot of those kind of people in the
| world, at least a lot that use their voice.
|
| But in the end, I never regret becoming a software engineer, and
| I also realized that it has profoundly shaped who I have become.
| bashwizard wrote:
| And then you switch to security from being a developer and the
| imposter syndrome hits you in the face like a truck and you'll
| realize how easy it was being a developer.
| dudul wrote:
| > software engineer is one of the hardest jobs.
|
| I chuckled. How can someone write this with a straight face?
| francisofascii wrote:
| If you think it is easy, it is because you have a talent for
| it and have years of experiance. People who are mental health
| professionals, teachers, doctors, CEOs, all have what I
| consider harder jobs, but do you think they would want to
| switch places and be a software developer 40 hours a week?
| They would think it is too hard.
| dudul wrote:
| There is a medium between "easy" and "hardest job in the
| world".
|
| People really live in a bubble. Try being a nurse working
| in cancer kid unit for a few years like my wife. Try being
| a trucker who sees their kids every other week. Don't you
| think these people would love seating in their chair from 9
| to 5 and make 6 figures?
|
| Maybe I misunderstood what the OP meant by "hardest". I
| sincerely hope so.
| francisofascii wrote:
| Agreed. Hardest is a high bar. Maybe OP was referring to
| those roles on a software team: developer, tester,
| business analyst, PM, client manager, etc.
| sanderjd wrote:
| There are just different kinds of "hard". I have lots of
| nurses in my family who have worked in ERs and ICUs, some
| of whom nonetheless have told me "I could never do what
| you do". I think they could! What I do seems way easier
| to me! But that's not how they see it.
| sanderjd wrote:
| Yep, everyone I know who isn't already involved in creating
| software, including a number of people I know who do jobs
| that I think of as being actually-hard, thinks it seems
| really hard and magical. Like, not the job aspect of it
| that we're mostly discussing here, but the "writing the
| code that makes computers do all this stuff" part, that
| probably strikes 95% of the people reading this thread as
| pretty easy at this point. It's just that it's easy to do
| things you already know how to do.
| mk67 wrote:
| Don't think it's necessarily wrong though. I can't think of
| many professions where a large amount of professionals are
| pretty bad at their jobs.
| fjfaase wrote:
| Of course, it is difficult to compare jobs with respect how
| hard they are. One could easily argue that every job is hard.
| Jobs can be demanding in various areas, such as: physical,
| emotional, psychological, mental and intellectual.
|
| Some thins, I think, make software engineering hard, is
| because it is not very visible from the outside. Another
| reason is also that it is different from other forms of
| engineering, where the product of the engineering is outside
| the engineering and where it is often easy to add a margin.
| With software, a very small bug can have big consequences.
|
| I also think that software developement is a very creative
| profession, while often not viewed as such, where you are
| often judged on the basis of your creative output. In a sense
| software developers struggle with similar problems as
| artists, where there is often not an objective good or bad.
| Discussions about coding styles are frequently found here on
| Hacker News.
| lambic2 wrote:
| OP means mentally/intellectually hard, not physically hard.
| dudul wrote:
| So?
|
| As I said in another post, is it harder than working with
| cancerous kids? Or being on the road for days to only see
| your family every other weekend?
|
| Are you really claiming that it's easier than bickering
| with the PM during standup?
| jampekka wrote:
| If only software engineering required or even encouraged
| thinking, let alone deeply.
|
| Formal systems like computer programming, mathematics or
| accounting do depend on a certain style of thinking, but I
| don't think it's especially hard or deep. If something it's
| shallow and simplistic (which of course has its place).
| Tainnor wrote:
| > Formal systems like [...] mathematics [...] do depend on a
| certain style of thinking, but I don't think it's especially
| hard or deep.
|
| I'm awaiting your proof on whether P is equal to NP.
| jampekka wrote:
| Why? At least I'm not waiting for mathematicians to e.g.
| negotiate peace in middle-east, produce a room temperature
| superconductor or raise a well functioning triplet.
|
| (Obviously me doing those is even more unlikely than me
| doing P=?NP, but I'm not sure how I'm involved here.)
| Tainnor wrote:
| Don't you see the issue with claiming that "mathematics
| is shallow and simplistic", but then not being able to
| follow up on that claim by actually solving one of the
| most famous open mathematical problems?
|
| If it were shallow and simplistic, any moderately
| intelligent person would be able to do it - yet decades
| of world-class mathematicians have failed to produce a
| proof.
| jampekka wrote:
| I did not mean shallow and simplistic in a way that any
| moderately intelligent person would be able to do it.
| Also all (most) mathematics is not P=?NP level stuff.
|
| Especially being simplistic (unambiguous, mechanistic) is
| a feature for what mathematics is used for.
| Tainnor wrote:
| > Also all (most) mathematics is not P=?NP level stuff.
|
| The list of open mathematical problems is as varied as it
| is vast. But even going beyond that, it's clearly evident
| (e.g. by considering drop-out rates of technical degrees)
| that most people seem to be having a really hard time
| even with comparatively elementary mathematics.
|
| > Especially being simplistic (unambiguous, mechanistic)
| is a feature for what mathematics is used for.
|
| I'll give you "unambiguous" up to a point (there's still
| enough debate about which axioms are the "correct" ones,
| though). But "mechanistic" is plainly wrong. The set of
| true theorems (e.g. of ZFC) is famously undecidable, so
| there can be no algorithm that can capture all of
| mathematics.
| askonomm wrote:
| This actually describes the job pretty well in my opinion, as
| someone who has been in this field for over a decade now. Not
| everybody is cut out to be a software engineer, and the "day in
| the life of" youtube videos where they never do any work and just
| eat all day of free food and socialize just paint an inaccurate
| picture of reality, making the job seem a lot more glamorous and
| easy than it is.
| tomaytotomato wrote:
| I generally find I write perfect clean code in my own personal
| projects, however at work my colleagues keep complaining about it
| ;)
| bradfa wrote:
| You will almost certainly experience a layoff in your first few
| years of post-college work. You may or may not be affected
| directly by the layoff, but either way your first layoff
| experience makes an impact on you. You will watch others around
| you who may have even been great at their jobs lose their jobs
| for no fault of their own. It sucks.
|
| When a layoff happens to/around you, TALK ABOUT IT WITH YOUR
| PEERS! Every one of your peers will be having feelings. Engineers
| are not good at talking about feelings. But OMFG seriously, when
| that first layoff happens just drop everything you're doing, grab
| a pile of people you work with and go out for a long lunch right
| away and then talk about wtf just happened. It makes the
| situation less bad and will help you get back to being productive
| much quicker. Your boss won't mind, and if they do, they're a
| horrible person.
| LoganDark wrote:
| > if they do, they're a horrible person
|
| Very bad gamble if you need the job and a bunch of people just
| got laid off. If you can afford to move jobs, you would have
| done it already after the layoff.
| bradfa wrote:
| My first internship in college, on my last week, my entire
| organization got laid off. We all went out to lunch at 9am,
| none of the engineers went back to the office that day. My
| first job after college, I was there for 6 years, we had I
| think, 11 layoffs in organizations I worked in, the first one
| was less than 6 months after I joined. My 3rd job after
| college, I was there for 5 years, we had at least 3 different
| layoffs.
|
| In all cases the managers were completely understanding about
| the mental impact of the layoffs, both for those directly
| affected and those who kept their jobs and would need to pick
| up the work of the departing. Never once did I see a manager
| expect any work to be done the rest of that day after a
| layoff was announced.
|
| If you ever work for a manager who isn't compassionate during
| a layoff, I'm sorry, that sucks.
| Tao3300 wrote:
| > You will almost certainly experience a layoff in your first
| few years of post-college work.
|
| Or you'll get hired on the cheap right after the layoff, and
| everyone left behind will hate your fucking guts for it.
| Especially when you need their help.
| bigpeopleareold wrote:
| - First job: laid off. Found a new position in 2 weeks. -
| Second job: wanted to move, so this doesn't count - Third job:
| laid off. But I was already looking for new jobs, it just
| worked out really well for me
|
| For the ones I got laid off - severance pay is always a nice
| bonus, particularly if you can get a job prior to it running
| out. Just remember that when a layoff happens, it's can be more
| beneficial than a loss (both in monetarily and shaking up
| things a bit to find new stuff to do.)
| Tknl wrote:
| I think the point with regards to clean code is somewhat
| changing. As companies and their clients adopt process
| certifications such as ISAE, static code analysis reporting is
| slowly becoming a requirement for the release process, driving
| measured code quality improvement and directly tying it to
| business outcomes. I feel like some other points are also less
| severe in technology oriented companies focused on cloud native,
| continuous delivery and that manage based on the DORA metrics.
| geraldwhen wrote:
| It is extremely easy to disconnect from work. Turn off your
| laptop and live your life.
|
| I find that those who are chronic workers have very little going
| for them in their personal lives.
|
| I challenge everyone who feels overworked to work 1 hour less
| this week, then an extra 1 hour next week. See how far you can go
| before anyone even notices or cares. It's farther than you think.
| dools wrote:
| > I find that those who are chronic workers have very little
| going for them in their personal lives.
|
| Yeah having kids fixed that for me
| fjfaase wrote:
| I often find myself at totally random moments thinking about
| problems related to work. It is often at times that I have been
| away from the laptop, that solutions pop-up in my mind, for a
| nasty problem. Often it is form of attacking a problem from a
| different direction.
|
| For me turning of my work laptop is not enough to disconnect
| from work. Most of the thinks that I worry about while being at
| home are not about technical aspects but about non-technical
| aspects of the job: dealing with managers, colleagues, and
| project organisation.
| martinclayton wrote:
| Same here. I have no trouble "closing the laptop", but I
| can't stop my mind from problem solving. Fortunately for me I
| don't have any of the "soft" concerns you mention.
|
| The practical side is clear: close the laptop. But on the
| mental side I do wonder where the right balance is. I've
| recently started to forget about work at the weekends to the
| extent that - usually late on a Sunday - I suddenly remember
| I have to be at work the next day, which is an odd sensation.
| Probably just getting old(er).
| imhoguy wrote:
| Looks like you just had busy and nice weekends then. I get
| the same deep reset weekends sometimes, especially when I
| also take Friday off. Then the next Monday morning I barely
| remember what to say at the daily stand-up confessional.
| geraldwhen wrote:
| That sounds like anxiety. Nothing is so important that it
| can't wait for business hours.
|
| And if the company will fail or you would be negatively
| judged for only working on business hours, there are always
| other jobs.
|
| Writing down a shower thought that hits you out of your
| subconscious is one thing, but actively considering work
| topics off work time is working more for the same pay.
|
| My interactions with colleagues are pleasant enough that I
| don't need to worry about them at home. And things like
| "resource allocation" happens on work time
| porker wrote:
| Or ADHD. That means that I wake up thinking about things -
| work, house tasks - and I don't get to switch off in the
| way that you do.
| runeks wrote:
| > I often find myself at totally random moments thinking
| about problems related to work. It is often at times that I
| have been away from the laptop, that solutions pop-up in my
| mind, for a nasty problem. Often it is form of attacking a
| problem from a different direction.
|
| I get this too, all the time, but I don't see it as a
| problem. This is what the mind likes to do: chew on problems.
| It's not realistic be expect to be able to prevent your mind
| from trying to solve problems. All you can really do is to
| not pay it too much attention and it eventually dies out.
|
| If a solution to a work problem pops into my mind, I just
| write down a few key words on my phone and continue with my
| day. Then I revisit the notes on my next work day.
| quietbritishjim wrote:
| That section of the article unfortunately conflates two types
| of not switching off.
|
| * Late at night, quick check of my email or Slack and maybe
| even reply (either to get it out of the way or to show off how
| hard I'm working).
|
| * While I'm in the shower, thinking about some interesting
| logical problem (can be something mundane like how to clearly
| express something in a report).
|
| What is healthy and what isn't is subjective. But most would
| agree the first is not healthy, while some would say that the
| second is OK. Personally, I think it's fine (nice even) and
| certainly doesn't interfer with social or family life.
|
| You (comment I'm replying to) have added a third which is quite
| different: "chronic workers" are those that are flat out
| working for extended hours. That's not really the same as not
| being able to switch off.
| nikolayasdf123 wrote:
| you kidding me. have you heard about 24/7 oncall?
| geraldwhen wrote:
| I don't take any job where I would have to wake up from sleep
| to handle something. Some jobs have stated on-call, but the
| consequence of not handling a 3am call is nothing. In which
| case you make more money/hour by not responding to night
| requests.
|
| The products I've worked on in my career largely operate on
| US business hours, so this has never been a real issue for
| me.
|
| If I were receiving calls about work more than once a year,
| I'd quit.
| jwmoz wrote:
| Couldn't agree more. Worked with a guy and he would respond on
| slack almost immediately-he was addicted to work and having the
| app on his personal phone. he had nothing else going on in his
| life.
|
| Personally, if I shut my laptop there is no way to contact me
| for work related issues nor should there be.
| Aeolun wrote:
| > having the app on his personal phone
|
| That's hideous. If you are going to carry it around
| everywhere anyway at least use your work phone for
| everything. That way you get at least _some_ of the upside
| (work pays for it).
| Aeolun wrote:
| > It is extremely easy to disconnect from work. Turn off your
| laptop and live your life.
|
| The problem is not that I can't stop work. I can sit around for
| a week and nobody would notice. It happens.
|
| But when I do work, I care. I want it to be nice, beautiful and
| make everyone's lives easier. And I want that _now_. I cannot
| just flip those switches off when I go home (or am home, when
| doing wfh). It would probably be objectively better if I rested
| my mind a bit, but my work happens in big bursts.
| intelVISA wrote:
| I felt this.
|
| Only way to find peace with this mindset is to go all-in on
| your own dream(s) not your boss' dream. May require a leap of
| faith...
| AnonCoward42 wrote:
| > I find that those who are chronic workers have very little
| going for them in their personal lives.
|
| Isn't that a truism? If you only work, there is not much time
| for anything else, I think.
| geraldwhen wrote:
| It is, and yet I suspect many chronic workers can't recognize
| it as one.
|
| It is obvious from a Birds Eye view, but those stuck in the
| toil rarely understand that they are losing their chance to
| build a meaningful life apart from work.
| gopher2000 wrote:
| > It is extremely easy to disconnect from work.
|
| Clearly that's not the case for everybody. Don't assume that
| your reality - and what works for you - is universal truth.
| bigstrat2003 wrote:
| Considering that the author of TFA assumed (wrongly) that his
| inability to disconnect from work is a universal problem, I
| don't think it's fair to criticize the comments here for just
| following his example.
| guappa wrote:
| Once a coworker spent 4 weeks arguing with me that his code was
| fine because "the test was green" before I touched it.
|
| The test contained a "return true" before the actual test.
|
| After writing countless emails to convince him to fix his code,
| and wondering why they wouldn't just fire him and save everyone
| else some time, the CTO announced that the guy was now promoted
| to team lead. :)
|
| His code is not elegant, it barely works, requires constant full
| rewrites, is an endless source of segmentation faults, deadlocks,
| sleep() in the main thread and whatnot.
|
| The only skill you need to get promoted is to laugh at the jokes
| of your boss and schedule meetings to demo your n-th rewrite of
| the same thing.
|
| Estimates are important.
|
| I've overheard a team lead claiming they are completely
| impossible.
|
| How long does it take you to go to the store? Yes you might die
| in the process and take [?] time, but one normally considers
| common inconveniences in this. A senior who can't estimate isn't
| a senior.
|
| Of course at work I've heard a team lead say "I did my part, I
| have no idea when they will implement it" (not the same team lead
| I mentioned before).
|
| > It will be almost impossible to disconnect from your job
|
| I learnt that very early on. In my first full time job, my boss
| got mad at me for arriving at the office at 9:05, unacceptably
| late.
|
| So precisely when my hours were done I'd stand up and leave.
|
| > talk directly to them, be professional but not mean, and tell
| them what and how they can improve
|
| And then get reported to HR... my advice is to be the 1st one to
| do the backstabbing and complain that it is impossible to work
| with them.
|
| > Get used to being in meetings for hours
|
| Working from home helps... one can cook and build lego during
| meetings.
| siva7 wrote:
| Remember Rule 10: Soft skills over technical skills. I'm sure
| the team lead has some qualities.
| chasd00 wrote:
| I told a guy I mentor this once. You can make a career out of
| only knowing the right people and you can make a career out
| of only knowing the right things. The situation you want to
| be in though is knowing the right people AND knowing the
| right things. That's where the real money is.
| guappa wrote:
| The only skill he has is sucking up to his boss.
| pjc50 wrote:
| > After writing countless emails to convince him to fix his
| code, and wondering why they wouldn't just fire him and save
| everyone else some time
|
| I do wonder whether this was escalated, to either the previous
| team lead, some other manager, or just a shouting match in the
| corridor.
| guappa wrote:
| Eventually my team lead asked me what was going on (he
| probably had gotten complaints about me breaking the tests).
|
| I told him what I had done (which is easy to show in a git
| show commit_id) and I guess he responded to them saying that
| we would not revert the change.
|
| In general I prefer to not have in person discussions for
| conflicts, so that there is a trail left behind, and I can
| take hours to respond, so I don't get heated up.
| donatj wrote:
| To be fair, the best team leads I have had were all far from
| the strongest developers on the team.
|
| The best team leads job isn't to dev, it's to represent the
| teams interests to the larger organization, and I have known
| some people who have really gone to bat for us, while at the
| same time barely being able to code genuinely getting angry at
| CI for pointing out obvious problems with their code.
| fjfaase wrote:
| Count yourself lucky.
| guappa wrote:
| I hope there are a few in-between steps between "strongest
| developer" and "actively destroying what others are doing"
| dasil003 wrote:
| Dude I don't know. Representing the team means understanding
| and making sure the architectural approach and
| interfaces/contracts with other teams are solid and will
| stand the test of time. This is certainly different from
| leetcode skills, but I've never seen a truly bad coder have
| any success at it.
| roland35 wrote:
| If they aren't the best developer but realize that then it
| isn't a problem - it's when you have someone who is terrible
| and thinks that they're great!
| PH95VuimJjqBqy wrote:
| If by team lead you mean manager, sure. If by team lead you
| mean tech lead, absolutely not. They should be one of the
| strongest developers on your team.
| ClumsyPilot wrote:
| > After writing countless emails to convince him to fix his
| code, and wondering why they wouldn't just fire him and save
| everyone else some time, the CTO announced that the guy was now
| promoted to team lead. :)
|
| It is. commonly known that some good developers make poor
| leads. Could some poor developers make decent leads?
|
| After all, most serion management has never seen an if-clause,
| are they any better than this guy?
| bbarnett wrote:
| Maybe. But if the accounting is accurate, this person refused
| valid, and urgent criticism. They refused all input, and
| eefused to care that there was an issue.
|
| This would make a very poor team lead. Imagine this person
| taking the wrong path, then refusing to acknowledge so.
| Imagine them upset that "their" path was being constructively
| criticized.
|
| This is how companies go bankrupt, how months or years of
| work result in garbage.
| ClumsyPilot wrote:
| Maybe thats exactly how management acts in this firm?
|
| They looked at complaints about this dude's behaviour and
| go "clearly one of us!" ^^
| guappa wrote:
| Oh yeah the account is accurate.
|
| At some point I had to use a C library written by him.
|
| Due to segmentation faults I decided to just rewrite it by
| myself (in less than 200 lines).
|
| He holds a grudge against me because of that.
|
| When I showed with benchmarks that a sleep() in a loop in
| the main server thread is not a great idea he said "don't
| fix what isn't broken".
| ClumsyPilot wrote:
| djamn, this is painfull
| fjfaase wrote:
| I would almost add another point to the list of 10 points: Your
| worse software engineering colleagues will often get promoted
| to do something else. Expect them to become your team lead.
| 2-718-281-828 wrote:
| > The only skill you need to get promoted is to laugh at the
| jokes of your boss and schedule meetings to demo your n-th
| rewrite of the same thing.
|
| don't blame the player, blame the game.
| nikolayasdf123 wrote:
| without the player there will be no game. blame the player.
| stcg wrote:
| I disagree with this statement in general.
| Institutions/nature (the game) cannot be held accountable.
| Persons can be. If we want to change the world, it starts
| with changing the behaviour of individuals, slowly changing
| the institution.
| psds2 wrote:
| The person who needs to change their behavior is the hiring
| decision person. The player is just making the best of his
| situation. The fact that the game is running means the most
| likeable person will be promoted, even if they aren't liked
| much.
| rightbyte wrote:
| The players should cooperate to not end up with someone
| bad for the players being promoted.
| speed_spread wrote:
| When there is no rulebook, definitely blame the players.
| hotnfresh wrote:
| I'm only learning to play correctly in mid-career. No amount
| of being good at technical stuff will get you promoted in
| most orgs--maybe to mid-tier dev levels, but not much higher.
| Being hyper-social, will. Not the normal amount of social you
| need to be to do a good job as a developer, but spreading out
| your "footprint" on purpose so you're known by and often
| interacting with a lot more people, even if those
| interactions are actually a drag on overall productivity.
| I've learned from observing others who are good at doing a
| lot of talking in meetings, and who eagerly start adding shit
| to people's calendars and stuff their first week. It fucking
| _works_. Reliably. Be bold, and be noisy. Get promoted.
| PH95VuimJjqBqy wrote:
| Do you really want to be promoted?
|
| I certainly don't, I'm fine where I'm at (software
| architect).
| yodsanklai wrote:
| > The only skill you need to get promoted is to laugh at the
| jokes of your boss and schedule meetings to demo your n-th
| rewrite of the same thing.
|
| You can't choose your colleagues, but you can choose your
| company. Some of them have fair evaluation processes and try
| hard to avoid biases. Same thing for meetings, not all
| companies/teams have long meetings.
| sam_lowry_ wrote:
| "If you can't change the organisation, change the
| organisation"
| 28304283409234 wrote:
| Or change your own perception.
| Aeolun wrote:
| I don't think this is completely true. There's a limit to how
| often you can force yourself to run the interview gauntlet.
| nanidin wrote:
| Have you tried changing companies? That sounds like a very
| toxic environment.
| guappa wrote:
| Last time I tried that I ended up in a company that was full
| of racists... I had to leave in a couple of weeks.
| bobmaxup wrote:
| > I've overheard a team lead claiming they are completely
| impossible.
|
| How big was the team? What were their responsibilities?
|
| I have worked places where, because of bad management, we
| dropped everything to shift to other tasks so often that it was
| nearly impossible to estimate anything.
| guappa wrote:
| team of 4 including himself.
|
| They seem to have a lot of spare time and work on toy
| projects often.
| baz00 wrote:
| Lego during meetings. Now there's a good idea. I'll take that
| one away as good advice!
| jnsaff2 wrote:
| > The only skill you need to get promoted is to laugh at the
| jokes of your boss and schedule meetings to demo your n-th
| rewrite of the same thing.
|
| Matt Levine wrote another epic LOLfest about a similar topic
| yesterday. [0][1]
|
| I recommend subscribing to his column as the email is always
| full length piece without the paywall.
|
| [0]
| https://www.bloomberg.com/opinion/articles/2023-11-07/bridge...
|
| [1] https://archive.ph/CQUn9
| bondarchuk wrote:
| Is there something wrong with archive.ph lately? I only get
| infinite captchas. Yesterday same thing on another article.
| It was a great service when it worked.
|
| Edit: seems to be an issue with DNS over HTTPS, change
| provider from cloudflare to nextdns solved it (per https://ww
| w.reddit.com/r/AskTechnology/comments/162w00q/gett...)
| pif wrote:
| > His code is not elegant, it barely works, requires constant
| full rewrites, is an endless source of segmentation faults,
| deadlocks, sleep() in the main thread and whatnot.
|
| A lot of negative points, indeed, but the first priority is to
| ship new functionalities. If he was the only one focused on
| shipping, while you others loved to get lost in useless
| architectural debates, he was the best candidate to team
| leader.
|
| Corollary 1: clean, maintainable code is only important when
| you have _customers_ expecting maintenance.
|
| Corollary 2: in the Real World (tm), the alternative to
| technical debt is getting out of business.
| quickthrower2 wrote:
| Not testing your code though. Places that value that shit
| speed at any cost eventually go bust, it is not smart and
| indicates a dumb culture which probably carries over to
| strategy and financials. That has been my experience. There
| is a basic level of standards. No need for architectural
| astronauts or monad fanatics but some sanity!
| pif wrote:
| > There is a basic level of standards.
|
| I agree with you, and it's very simple to define such a
| level: use as much discipline as you need to ensure
| shipping features at an acceptable rate in the long term.
|
| Too much polishing lowers your release rate. Too little
| discipline will hurt the "in the long term" part.
| quickthrower2 wrote:
| Thats a good way to put it. Shipping value rather than
| features though. Which is represented as long term
| shareholder value, but within some kind of ethics (don't
| fuck the customer type stuff).
|
| Thinking in terms of value could mean you sometimes
| suggest weird things like removing features, cancelling
| WIP (sunk costs) etc. when appropriate. Or spending way
| more time polishing than seems necessary or conversely
| getting something out that looks way too quick and dirty.
| There are cases where no tests are OK despite what I said
| but usually MVP stage stuff where no market fit exists
| yet.
| arethuza wrote:
| "Places that value that shit speed at any cost eventually
| go bust"
|
| That has not been my experience...
| quickthrower2 wrote:
| Have you experienced just speed. Or speed at any cost?
| I.e. releasing really buggy features that customers
| complain about and churn on? Obviously with enough VC and
| marketing dollars anything could be possible.
| guappa wrote:
| > A lot of negative points, indeed, but the first priority is
| to ship new functionalities. If he was the only one focused
| on shipping, while you others loved to get lost in useless
| architectural debates, he was the best candidate to team
| leader.
|
| But the functionalities don't work and generate customer
| support load...
|
| I should perhaps mention the time he compiled a binary on his
| machine, committed it on github and went on vacation. And
| then we couldn't fix the bug that needed urgent fixing.
|
| > Corollary 1: clean, maintainable code is only important
| when you have customers expecting maintenance.
|
| We do have customers yes.
|
| > Corollary 2: in the Real World (tm), the alternative to
| technical debt is getting out of business.
|
| You're defending this guy so much... why so defensive? Do you
| reject the notion that incompetents exist?
| pif wrote:
| > But the functionalities don't work and generate customer
| support load...
|
| And this is the first issue you should have mentioned! All
| the rest is peanuts...
| pif wrote:
| > You're defending this guy so much... why so defensive? Do
| you reject the notion that incompetents exist?
|
| I'm not defending him. I'm just refuting that a developer's
| competency can be judged without taking into consideration,
| first and foremost, the benefits he produced for the users
| of his software.
| switchbak wrote:
| Shipping broken, especially code that looks ok but it
| secretly broken - is far worse than having no code at all.
| Once it's in place, it gets dug in like a tick, and if it's a
| pile of poor assumptions and wrong logic, you're in a much
| worse spot than you were with a clean slate.
| Apes wrote:
| If everyone else is spending all their time cleaning up the
| broken shit he built but won't fix, and he continues to
| produce more broken shit faster than everyone else can keep
| up with fixing it, he is a 10X programmer. Not because he's
| actually 10X better, mind you - he just makes everyone else
| 10X slower.
| mcguire wrote:
| Corollary 3: This is one reason why many businesses deliver
| one product and then sink without a trace.
|
| Corollary 4: Never buy version 1 of anything.
| quickthrower2 wrote:
| He gets promoted = double click cv.doc and get updating for me.
| Team leading is about people but fuck you need some level of
| competence. Infact I say you need more technical skill in some
| ways to be across everything. How will this TL have high
| standards if he short circuits his unit tests and then fiercely
| argues for it?
| guappa wrote:
| He doesn't have standards. Last time I had to do with that
| team, the only test the code had passed was "it compiles".
|
| Surprisingly, it didn't work.
| EVa5I7bHFq9mnYK wrote:
| >> the only test the code had passed was "it compiles"
|
| He might be really good at type systems!
| quickthrower2 wrote:
| With Haskell, if it compiles then it works. But not for
| the reason people think. If you spent the time learning
| Haskell, you probably are smart, conscientious and
| thought quite hard about your program.
|
| That said type obsessed people invent things like
| property based tests (basically fuzzers for math people).
| They test the shit out of their code!
| roenxi wrote:
| > How long does it take you to go to the store? Yes you might
| die in the process and take [?] time, but one normally
| considers common inconveniences in this. A senior who can't
| estimate isn't a senior.
|
| A senior who can't navigate the politics around estimating is
| missing key skills. But they still can't estimate. To estimate
| something you have to know what you are building and the steps
| to take to build it in advance. Senior engineers usually don't
| have enough political weight to stop that changing half way
| through a project and therefore cannot provide estimates. They
| can estimate hypothetical scenarios that are unlikely to
| happen.
| guappa wrote:
| It's called "estimation" because it's not supposed to be
| precise.
|
| Of course the only way to obtain a precise measurement is to
| start the clock and do the thing.
| porker wrote:
| And yet in the politics of a company, an estimate becomes
| fact, and then if you don't meet it they are angry.
| guappa wrote:
| Am I the only one who watched star trek?
|
| Estimate, multiply by 4, give the number.
| Hikikomori wrote:
| It will take 4 units of time, time units are subjective.
| GaelFG wrote:
| I dont know if you are joking but when managing i do
| exactly that and that work (with a factor of 3 to be
| precise, with most people, some aldready take that into
| account). Works also with myself, i askmyself 'how much i
| think it will take, i double it and i assume half the day
| i will be bothered by other unplanned things'. It work
| remarkably well especially for longer projects.
| guappa wrote:
| https://www.youtube.com/watch?v=t9SVhg6ZENw
| benhurmarcel wrote:
| I was always told to multiply by pi. Results that are not
| round numbers look more thought-out.
| sometimesweenie wrote:
| Much like estimates, pi is irrational
| arethuza wrote:
| And pi squared if it is a new team doing something new...
| lucumo wrote:
| There's a three-pronged approach when dealing with it:
|
| - Pad.
|
| - Communicate risks.
|
| - Communicate assumptions.
|
| Then when assumptions are wrong, immediately communicate
| that this will change the estimate. When risks hit,
| communicate that a risk hit, and whether or not you can
| absorb the impact in the planning. If not, communicate
| the expected delay. Pad that too.
|
| Communicate, communicate, pad, and communicate.
|
| (Padding, BTW, may feel dishonest, but it isn't. It is
| making the assumption that a certain share of you risks
| will strike and making allowances for that.)
|
| If you still get in trouble for missing estimates, pad
| more and communicate in writing. Then when people start
| blaming, you can point to the emails sent. To their/your
| boss if necessary.
| Volundr wrote:
| > (Padding, BTW, may feel dishonest, but it isn't. It is
| making the assumption that a certain share of you risks
| will strike and making allowances for that.)
|
| This. It helps to realize that when someone asks "how
| long will X take". What they are actually asking is "When
| can I rely on X being done by?". If you say 2 days and it
| takes one, no problem. But if you say one and it takes 2,
| they've already told the client it'll be done tomorrow,
| arranged for the machinery to be in place, and now
| everything is jammed up based on your delay.
|
| Estimating is as much art as science and requires
| understanding the context around the estimate and how it
| will be used.
| PH95VuimJjqBqy wrote:
| also offer alternatives, preferably at the same time you
| communicate the risk. When the risk hits you can then
| start making recommendations about the workarounds you've
| already communicated.
|
| This stuff is fluid but too many technical people feel as
| if it's not.
| wccrawford wrote:
| I've been to the store before. A _lot_. I 've never hooked in
| new library X to the codebase and implemented that new
| functionality.
|
| Estimating things you've never done is _hard_.
|
| Estimating things you've done a lot is trivial, and pointless.
|
| When people saying that estimating is hard, they don't mean
| they easy kind.
| Clubber wrote:
| "I want you to build a document management system, how long
| will that take?"
|
| Uhhhhhhhhhhh....
| saalweachter wrote:
| "It will take me X weeks... to come up with a reasonably
| accurate estimate."
| guappa wrote:
| It will take 2 months to gather the actual requirements and
| be able to do an estimate.
| wheresthebeef wrote:
| This guy consults.
| rawgabbit wrote:
| From my experience, the two months of gathering
| requirements will be more valuable than developing
| something from zero requirements. Whatever you code with
| always be "wrong" because with zero requirements there is
| nothing to test against.
| baq wrote:
| the correct answer is 'yes'
| speed_spread wrote:
| Fork an existing one, slap your name and logo on it. 2
| points.
| locustmostest wrote:
| Exactly. We'd love it if more people did that with our
| document management system.
| (https://github.com/formkiq/formkiq-core)
| Izkata wrote:
| "This is git. Have fun!"
| orwin wrote:
| Estimate are for accountability. It's for team management.
| That's why middle management shouldn't have access to
| estimates imho.
| sixothree wrote:
| The issue everyone is skirting here about estimates is the
| unknowns. Letting management know what the unknowns are and
| how confident you are you can resolve them is just as
| helpful as providing an accurate hour estimate.
| lcnPylGDnU4H9OF wrote:
| Even on the store point: I might notice I'm low on fuel and
| fill up on the way. Easily turns a 15-minute errand into 20
| minutes. Estimations in the context of a software project are
| similar to a promise that my trip to the store will only be
| 15 minutes which I'm held to even if I notice the low fuel
| gauge.
| ozim wrote:
| I like the store metaphor.
|
| Shopping list is set and I should be in and out in 15 mins
| but it turns out there is no ketchup - so do I go to
| another store to get ketchup or mustard will do. Product
| owner my Girlfriend has to decide because she is doing the
| cooking and will present it to customers our guests, and
| she knows if they like mustard or not because she talks to
| them more often than I do.
|
| But yeah going to another store might make dinner late and
| I cannot know this until I actually arrive at the store
| that there is no ketchup on the shelves.
| interactivecode wrote:
| Its a good metaphor also because if you have an
| appointment in 20min you would never go to the shop 15min
| before. Yet managers will force you still out and to the
| shop because of your time estimate.
| Volundr wrote:
| Part of estimating is accounting for those contingencies.
| Given above, depending on my audience the above estimate
| will be either 30 minutes, or 15 minutes but could be as
| long as 30 depending on these factors. Part of estimating
| is accounting for the setbacks one can (reasonably) expect
| to see, to give the other party a timeframe within which
| they can be (reasonably) certain it will be done.
|
| Of course there could be a fire on-route causing a jam that
| turns your 15 minute trip into 2 hours, but that's
| sufficiently unlikely it's probably not worth building into
| your estimate (but could be depending on the stakes
| involved! If someone is going to die you should probably
| factor this in so we can plan for that contingency). In
| that instance instead you need to communicate when it
| happens so that everyone involved can recalibrate.
| Tangurena2 wrote:
| I think the reason that estimating is hard is that no one
| ever returns to their estimates and tries to fix the
| estimates. What usually happens is that people throw out a
| number, mismanagers think that number is negotiable, and
| whether the project's completion is in any way related to the
| estimate - the estimate is forgotten.
|
| No one writes down "this is why I think the project will take
| X [time units]".
|
| And no one goes back to that estimate and says "I left Y & Z
| out of that estimate, I better include that next time."
|
| If you want estimates that have any relation to reality, your
| estimating process needs to have that sort of feedback.
|
| > _When people saying that estimating is hard..._
|
| I think they're referring to the sort where management
| negotiates the estimates, like you're haggling over something
| in the marketplace. If they have such a strong opinion about
| how long something should take, then asking you for estimates
| is setting you up for failure and blamestorming. _" It's one
| banana, Michael. What could it cost, $10?"_
| SpaceNoodled wrote:
| I've streamlined the process, and just say that anything
| will take five days to complete.
| sroussey wrote:
| Teams definitely refine and alter estimates as new
| knowledge of the problem space is discovered. It's a
| management (and team) failure if this does occur.
|
| Also, on the negotiation side of time it will take, I
| absolutely know for myself that I can code things fast and
| functional but a bit hacky, or beautiful and elegant and
| will take much longer.
|
| The negotiation should be about when to do which.
|
| At a higher level, you put your teams together within their
| temperaments in mind and match that to the work.
|
| Some code will be a nexus of changes and interaction with
| other code (invest early), and some code will get written
| once and never seen again (go fast and forget).
| PH95VuimJjqBqy wrote:
| One of the things that makes me so successful is that I
| always try and have a backup plan. "our goal is X, if we
| fail to meet that with approach Y then we'll use approach
| Z. Lets prepare for approach Z while we're also preparing
| for approach Y and evaluate and switch to approach Z as
| early as we possibly can. We still want approach Y so we'll
| continue working on it even if we start using approach Z to
| successfully launch".
|
| The issue is that there's a fluidity in that thinking that
| many many MANY technical people either don't have or don't
| employ.
| Joeri wrote:
| In my experience writing out assumptions together with
| estimates tends to improve estimate accuracy a lot, by
| challenging the assumptions (and estimates) more at
| estimation time, and making it more visible when changes
| occur at implementation time that impact estimates.
|
| As for negotiating estimates down, it is up to technical
| leadership to refuse to do that. Not easy, but doable.
| madeofpalk wrote:
| One of the most productive teams I worked on spent time at
| the end of an iteration to look back on our previous
| estimates and re-estimate them. We got much better at
| estimating the remaining work we had, and knowing whether
| we would hit deadlines or not.
| steamer25 wrote:
| My favorite is being asked to estimate a bug fix before I've
| had any chance to analyze the issue.
|
| It's like calling a mechanic over the phone and asking how
| much it will take to fix your car. The mechanic doesn't know
| if the engine just fell out of your Model T or if you're just
| trying to put the key in backwards. How about you bring it in
| first, then we'll look it over and go from there?
|
| Sometimes you can ask some questions and get to, "Well it's
| probably X which would take Y but we'll need to see". Then
| they get Y stuck in their head and it turns out to be the one
| time out of twenty when the cause isn't actually X but
| something much more involved.
| vkou wrote:
| If you're being asked to estimate a task without
| insufficient information on what the task is, punt it back
| with 'More information needed, we'll look at it 3 weeks
| from now in the next sprint planning'.
| danenania wrote:
| Accurate estimates are impossible, but you can get better at
| them. Getting better at them mostly entails increasing your
| estimate to the point that it feels absurd, and then doubling
| it. To become a true expert, double it again. Another
| approach is to always bump it up a unit of time. So an hour
| becomes a day, a day a week, a week a month, a month a
| quarter, etc.
|
| Really, you just have to be a pessimist. Instead of saying
| what people want to hear (it's simple and can be implemented
| quickly), you need to imagine the long-tail worst-case
| scenario where everything that can possibly go wrong goes
| wrong, then give that number. If people don't give you a
| somewhat incredulous look when you give an estimate, you
| probably were too optimistic. Just remind them that you're
| imagining a worst-case scenario and say that you hope to have
| it done sooner, but don't back down on your estimate.
|
| Another thing to realize: at the business level, deadlines
| are often picked arbitrarily to create urgency. The specific
| date of the deadline is usually less important than just
| having some deadline, any deadline, to motivate everyone.
| Business people will pretend the deadline is Very Important,
| but it's all an act, more or less (arguably it's a necessary
| one). Remember this when giving your estimates.
| PH95VuimJjqBqy wrote:
| > Accurate estimates are impossible
|
| disagree, not all tasks can be estimated accurately
| depending on circumstances but this does not imply that
| it's impossible to estimate any task accurately.
| danenania wrote:
| No matter what the task is, things can go wrong that you
| didn't anticipate.
|
| Maybe it's just a quick CSS change, but all of a sudden
| the webpack build starts mysteriously failing. And now
| your node_modules got corrupted and oops, when you delete
| it and reinstall dependencies, there's a dependency
| conflict. Once you've finally gotten that figured out,
| some tests are now failing in part of the codebase you've
| never seen before. Better make some coffee...
|
| Some version of this can always happen, and as a task
| gets larger, it is almost guaranteed to happen multiple
| times in multiple variations. Since you don't know what
| problems will arise, there is no way to know how long it
| will take you to fix them. You can stay up all night in
| order to pretend that your "quick and easy" estimate was
| accurate, but that only takes you so far.
| PH95VuimJjqBqy wrote:
| yeah, and maybe I'll have a heart attack and die while
| going to take a piss but that doesn't imply it's
| impossible to accurately estimate that it's going to take
| 5 minutes for said piss.
|
| What if, while cooking dinner, a meteor crashes in my
| kitchen and so my estimate of 30 minutes to cook dinner
| turns out to be incorrect? That _obviously_ means the
| conclusion is that it's impossible to accurately estimate
| how long it takes to cook that dish so we should never do
| so.
|
| There has to be a name for the type of reply your post
| represents.
| danenania wrote:
| Haha yes, webpack breaking or a test failing is
| equivalent to having a heart attack or a meteor hitting
| your kitchen.
| PH95VuimJjqBqy wrote:
| if your webpack or ci/cd pipeline is breaking often
| enough that you worry about it when delivering estimates,
| that's a you problem.
| danenania wrote:
| Are free ponies available in this magical land you speak
| of where nothing ever unexpectedly breaks? Please put me
| down for two.
| PH95VuimJjqBqy wrote:
| you mean the same world where no one has heart attacks
| and meteors have never hit houses?
|
| Both have been documented to have happened, yet somehow
| you didn't seem to think that should be taken into
| account when considering estimates for cooking and
| pissing.
|
| If your shit is breaking so often you're afraid to give
| an estimate, that's a you problem.
|
| And yes, we had an internal team that w/i the last 6
| months couldn't go a week without a deployment problem.
| Ask me why they no longer have that issue.
| OkayPhysicist wrote:
| Software has an unusually fat long tail, to an even worse
| extent than real engineering. The probability of
| _something_ unexpected popping up and inflating the time
| something takes by an order of magnitude is much, much
| higher than the likelihood of the same happening while
| cooking.
|
| This ends up coupled with the fact that practitioners (of
| anything productive) tend to think in terms of 50-ish
| percentile estimates (i.e., there's a 50% chance this
| project is done in this amount of time), whereas business
| people care about 90th-99th percentile estimates. In
| software, the difference between between a 50th
| percentile estimate and 90th percentile estimate can be
| more than an order of magnitude in time spent.
| danenania wrote:
| Well said. 50th percentile vs. 90-99th percentile
| estimates is a great way to put it.
| PH95VuimJjqBqy wrote:
| I'm going to repeat what I said to another poster.
|
| If your shit is breaking so often it's affecting your
| willingness to estimate, that's a you problem.
|
| I'm driving to another state for the thanksgiving
| holidays, and I have an estimate for how long that will
| take. Is it possible when I walk out to my car that the
| battery died the night before? sure. Am I going to factor
| such an unlikely event into my estimate? no. Does that
| imply it's impossible for me to accurately estimate how
| long that trip is going to take? No it doesn't.
|
| Only in software could someone be using a tool that
| constantly doesn't work and they never consider replacing
| it or fixing it. Imagine if a carpenter showed up to your
| house with a hammer whose handle fell off once or twice
| an hour but they expected you to pay them for the loss of
| productivity rather than purchasing a hammer whose handle
| doesn't fall off.
| OkayPhysicist wrote:
| Not quite sure how you found your way onto a tech forum
| without any understanding of what software development
| entails, but unlike carpentry, where every time you want
| a new wall the carpenter needs to go through the same
| process to make the wall, or in cooking, where every time
| I want a roasted turkey the cook needs to cook a turkey,
| software almost never does the same thing twice. If you
| find yourself doing the same thing twice, that's a tool
| problem.
|
| That produces a much fatter tail distribution, because
| you're doing someone that no one has ever done before,
| and thus no one knows exactly how long it's going to
| take.
| PH95VuimJjqBqy wrote:
| > software almost never does the same thing twice
|
| odd, because my experience is that your CI/CD pipeline
| does the exact same thing repeatedly.
|
| Perhaps the answer to your confusion about my experience
| is that I don't suffer tools that hamper my productivity.
|
| Put it another way.
|
| I ran a raiding guild for several years and about halfway
| through that stint I recruited a player that raised the
| bar for what I thought was possible. Perhaps you need
| your bar raised.
| arcanemachiner wrote:
| > Maybe it's just a quick CSS change, but all of a sudden
| the webpack build starts mysteriously failing. And now
| your node_modules got corrupted and oops, when you delete
| it and reinstall dependencies, there's a dependency
| conflict. Once you've finally gotten that figured out,
| some tests are now failing in part of the codebase you've
| never seen before.
|
| This is too real.
| NoGravitas wrote:
| [Managers] are like children. They want everything right
| now, and they want it their way. But the secret is to give
| them only what they need, not what they want. -- Montgomery
| Scott
| grecy wrote:
| > _I 've been to the store before. A lot. I've never hooked
| in new library X to the codebase and implemented that new
| functionality._
|
| Which is why you'll get better at estimating as you get more
| years of experience under your belt, and why estimating is
| something that seniors are better at than juniors.
|
| Even after 20 years you may never have hooked in new library
| X, but I'd be willing to bet you've done something kind-of
| similar, and your estimate will be more accurate than a
| person with 1 year of experience and has never done anything
| remotely similar.
|
| > _Estimating things you 've done a lot is trivial, and
| pointless._
|
| Keep in mind you are not providing the estimate for the
| person who has done the task many times, you're providing the
| estimate to people who have never done it before. So for
| them, it absolutely is not trivial.
| RHSeeger wrote:
| > How long does it take you to go to the store? Yes you might
| die in the process and take [?] time, but one normally
| considers common inconveniences in this. A senior who can't
| estimate isn't a senior.
|
| The problem tends to be that, a lot of the time, you aren't
| told what store nor what mode of transport you have. Or you're
| told both, but the store you were told to go to doesn't have
| what they want so you need to go to another store.
|
| In my experience, being able to estimate is about both
|
| - Being able to give an idea as to how long it will take given
| a list of assumptions, AND
|
| - Being able to highlight what the risks are that can cause it
| to take longer, and how much longer. Those risks sometimes
| include the fact that your assumptions were wrong in some way;
| and sometimes include lots of other things (dependencies, etc)
| EVa5I7bHFq9mnYK wrote:
| >> The test contained a "return true" before the actual test.
|
| And he could find the same amount of deficiencies in your own
| code. You can always find something if you search hard enough.
| AnimalMuppet wrote:
| You can always find deficiencies. But some code is
| objectively worse than other code, sometimes massively so.
| HideousKojima wrote:
| >And he could find the same amount of deficiencies in your
| own code.
|
| I'm amazed how many people in this thread seem to believe
| that it's literally impossible for one dev to be less
| competent than another, let alone by a significant margin.
| John Carmack is objectively a better developer than me, and
| by a huge amount, but I don't feel ashamed or like a lesser
| person because of it.
| gopher2000 wrote:
| > The only skill you need to get promoted is to laugh at the
| jokes of your boss and schedule meetings to demo your n-th
| rewrite of the same thing.
|
| This is some bullshit that losers subscribe to.
| hotnfresh wrote:
| > The only skill you need to get promoted is to laugh at the
| jokes of your boss and schedule meetings to demo your n-th
| rewrite of the same thing.
|
| As far as what the system _actually tells you_ your job is: it
| 's not to do good work, it's to be _perceived_ as doing good
| work. This is an important distinction.
|
| Notably, promotion in orgs makes demonstrating _non-
| programming_ skills more important than anything else.
| Communicating a lot, and well, is likely a much faster route to
| a better title and better pay than digging into fiddly
| technical problems and saving the day that way.
|
| You see a mediocre junior come in and carve a shockingly-fast
| path up the promotion ladder without ever getting good at
| programming--they're communicating better, and probably,
| especially, _a lot_ more. The most-visible get promoted. Talk
| more, email more, message more, speak up in meetings more,
| _call more meetings_. Make yourself prominent in anything
| process- or architecture-related. It doesn 't even need to be
| productive (most of that stuff's not).
|
| The sad truth of how to get paid more in most orgs.
| nicexe wrote:
| I mostly agree with the points but I hard disagree with point
| number 3.
|
| Clean code makes the project more easily maintainable. We
| generally try to keep a standard in code quality (and I would say
| 98% of the codebase we touch is well written). We also try to
| schedule refactoring rounds (but that doesn't always happen
| because of time constraints).
| Clubber wrote:
| He didn't say clean code was bad, he said nobody cares about
| your clean code. I assume he meant outside the development
| department.
| sanderjd wrote:
| That isn't true either though. Sure, they don't care about it
| as a first order thing, but they care about development not
| slowly grinding to a halt over time. And writing well
| structured code is one of the things the software side of the
| house does in order to do a better job delivering on that
| desire from the business. If nobody on the technical side has
| the credibility or trust to make that case, then that's a
| problem.
| Clubber wrote:
| >Sure, they don't care about it as a first order thing, but
| they care about development not slowly grinding to a halt
| over time.
|
| Most only care when it affects them or sales, not when devs
| are asking to allot time to clean up code or pushing off a
| release to fix wonky stuff. In my mind that's not caring.
|
| That's like people care that they can't walk up stairs
| without huffing and puffing, but not enough to actually
| diet and exercise. That's not actually caring, that's
| really regret.
|
| I'm fortunate though, my company gives a lot of credence to
| dev.
| sanderjd wrote:
| That situation sounds to me like the problem of the
| development org not being trusted by the company's
| leadership when they say "this will slow down short-term
| initiatives but speed up long-term ones".
| Clubber wrote:
| Yes, it's pretty common in my experience. Of course
| executive bonuses are granted based on short-term
| initiatives more so than long-term ones. When they
| finally reap what the sow, just blame dev. You don't get
| to be an executive without knowing how to politic.
| sanderjd wrote:
| Oh yes, I agree it is common! But not at all universal.
| trickstra wrote:
| In the article:
|
| > Don't get me wrong, people will expect you to write good and
| clean code.
|
| I can agree with this. Clean code is not "celebrated" because
| it is expected as normal. You won't get a raise for it. You
| could get problems for not writing clean. But when the business
| gets into a tight spot, they will accept shitty code that
| fulfills their desired goal over a nice clean and elegant
| solution delivered few days later. In this case, the shitty
| code could get you a raise.
| gumballindie wrote:
| > Meetings are an important part of the software development job.
|
| Imagine the folks building the Linux kernel or other popular,
| successul, and mission critical software projects sitting in
| meetings all day long.
|
| I genuinely think that meetings are the only way management can
| justify their existance and therefore commercial projects
| consider them as an "important part".
| pjc50 wrote:
| > Imagine the folks building the Linux kernel or other popular,
| successul, and mission critical software projects sitting in
| meetings all day long
|
| What do you think LKML is? It's a big continuous asynchronous
| meeting.
| yakubin wrote:
| "asynchronous meeting" is an oxymoron.
| gumballindie wrote:
| I suppose if we redefine words everything is everything.
| siva7 wrote:
| >> I genuinely think that meetings are the only way management
| can justify their existance and therefore commercial projects
| consider them as an "important part". reply
|
| Wait until you join management at some point in your career.
| gumballindie wrote:
| I did. And held few and to the point meetings. I could see
| how non technical managers were struggling, and that's how i
| know that some are simply clueless and serve no purpose
| within orgs. I managed a somewhat small number of devs -
| roughly 40, some distributed.
| quietbritishjim wrote:
| > There are a lot of formulas on how to do estimates, and
| everyone has their own rules. I also have my own rules.
|
| The actual way to produce estimates can be found in the excellent
| book _Thinking Fast and Slow_ by Daniel Kahneman: you have to
| consider a previous project (or, better, several of them) of
| roughly similar in size and scope, and use that as an anchor for
| this estimate. You 're allowed to add or remove a bit because of
| a slight difference in complexity. But the golden rule is never
| to say that this other project doesn't count because, although it
| seemed similar at the start, it encountered unexpected problems.
| That's the whole point!
|
| If you haven't worked on a project that large (or kept good
| enough notes about how long it took), well, tough luck, you can't
| produce an estimate, any more than someone who doesn't know any
| software dev at all can.
|
| Looking back at a project with this in mind I was surprised to
| find the distribution of subtasks (into 3 big buckets of "main
| complex logic", "simple GUI", "reports/presentations") was
| roughly equal rather than about 80% on the first one as I
| suspected. There's no way a rule like "add 40%" can help you with
| something like that.
|
| The book discusses a great example where they were preparing a
| university syllabus to teach various biases, including the
| underestimate bias and this very technique to avoid it, and they
| still underestimated how long it would take to prepare the course
| (even after being given information about how long previous
| courses took to prepare!).
| kqr wrote:
| Another recommendation in the same vein is _How To Measure
| Anything_ by Douglas Hubbard. And _Superforecasting_ by
| Tetlock. Estimation /forecasting (same thing different
| emphasis) is a problem we know quite a lot about, and we know
| how to train people to issue calibrated estimations.
|
| The first step to learning anything is figuring out how to get
| feedback on your performance. For estimation, probabilistic
| estimations are the way: https://two-wrongs.com/verifiable-
| software-development-estim...
| ClumsyPilot wrote:
| These aren't hard to swallow at all - how about this:
|
| _Good requirements do not exist_ - Writing good requirements is
| months of work -you have to interview business stake holders, ask
| challanging questions, you ahve to involve industry experts and
| have developers think, not code.
|
| Its safe to say this almost never happens.
|
| _Agile is an insidious ruse_ - its popular because it frees
| management from having to commit to planning and discovering
| requirements. However management still expects engineers to
| provide them outputs of waterfall - accurate estimates,
| architecture, etc.
|
| _CV driven Architecture is common_
|
| Engineers have a complexity addiction and feel inadequate and
| impotent if they are 'just building' something simple.
|
| So simple projects get bloated to inckude Kafka, kubernetes or
| some other buzzword of the year. Instead of discussing business
| problems and missing requirements, engineers prefer to discuss
| technical complexity. So they often commit to adding technical
| complexity before they've understood business complexity.
|
| Then when they hit business conolexity, they have no mental
| capscity or bandwidth left to address it
|
| _Communication between business and Eng is usually broken_
|
| To arrive at good design decisions, one person needs to have
| great understanding of business and technology. In most projects,
| this person does not exist. Design is riddled with qeustions like
| 'Do we really need to have feature X, it doubles complexity but
| only 5% of users would even care". To even understand that,
| business needs to communicate commercial information to
| developers, or developers have to educate business. This rarely
| happens, and so these decisions are usually not even identified
| rob74 wrote:
| The point about "incompetent people" is a bit harsh. "Competence"
| is rarely boolean - some people are smarter, some are less smart,
| but may have other qualities (e.g. being more thorough), some may
| not be that familiar with a certain technology etc.; that code
| you have to work on may look the way it looks because it had to
| be adapted several times to changing requirements without enough
| time to refactor it properly, not because the person who wrote it
| was incompetent. There are already enough young developers
| leaving university full of self-confidence thinking they are
| God's gift to the job market, so maybe a word or two about giving
| people the benefit of doubt before classifying them as
| incompetent is in order. That's not to say there aren't _really_
| incompetent people, but you should avoid jumping to conclusions
| too early...
| quietbritishjim wrote:
| Maybe, but the people I have worked with have been pretty
| heavily bimodal, especially by the senior level - many people
| in the "competent" bucket varied a bit but generally produced
| workable code (maintainable as well as works now). But there is
| a distinct class of senior engineer that produces awful code
| that is hopeless to work with later. Most frustratingly, it
| does actually work for the current task so those outside the
| system will only see problems with the later devs to work on
| it.
| Aeolun wrote:
| > But there is a distinct class of senior engineer that
| produces awful code that is hopeless to work with later
|
| The longer I work on stuff the more I worry this is me. I
| thought it was the code coming before me, but the code after
| seems just as error prone.
| BigJono wrote:
| There's a really easy way to tell.
|
| If I say something like "I've got my sales history in a
| database and need to graph how many widgets I've sold over
| time", do you start thinking about concepts and code, or do
| you start drooling and typing "npm database npm graph npm
| widget..."?
| hotnfresh wrote:
| Seasoned pro-tier for that specific sort of problem is
| just batch-exporting to excel and letting it do the
| graphing, or hacking something up in Power BI or
| whatever.
| throw555chip wrote:
| One point to make about thrown together solutions, in the
| following video:
| https://www.youtube.com/watch?v=TmhQCQr_DCA at time 8:32
| he changes Units Sold column from Decimal to Whole
| Number. For the trivial example, it would probably be
| fine but it could also be a costly mistake in other
| scenarios.
| the_sleaze9 wrote:
| We all start from somewhere and nobody was born starting
| from perfect.
|
| First label your fundamental concerns. You cannot improve
| what you don't measure.
|
| Error-prone code? First number the errors then classify the
| errors. Are your errors related to typos or do they come
| from not handling variable input gracefully? Now reduce
| your numbers by consciously finding typos, or by
| consciously mapping out just what inputs could possibly
| come in. Miss one? Write it down and never miss it again.
|
| Meetings? How many times do you get "well actually'd"? What
| specific areas do you get asked questions about?
|
| Coworkers? How many times do you get asked for help? How
| many times do you ask the same question -with or w/o a
| subtle variation- more than once? How often do you reach
| out to just shoot the shit? How often does someone approach
| you for water cooler talk?
|
| Or (more likely) you just _feel like you aren't competent.
| Having hard numbers will go very far in getting a more
| objective viewpoint there.
| jameshart wrote:
| The hard truth:
|
| Some days, _you'll be the incompetent person_.
| rob74 wrote:
| Or, to put it in the immortal words of U2, some days are
| better than others (https://genius.com/U2-some-days-are-
| better-than-others-lyric...)
| manicennui wrote:
| Being wrong occasionally is human. It is not the same as
| being incompetent. There truly are numerous people in
| software engineering who don't know what they are doing at
| all.
| kagakuninja wrote:
| On my current job, one guy took over a month to "write more
| tests for service X". He was finally fired (took over a year
| despite being clearly incompetent, and they had multiple
| opportunities to not renew his contract). After that, I saw
| that he had only written 6 tests, which were quick copy-pastes,
| and largely useless. Maybe this guy had some positive
| qualities, but writing code was not one of them.
|
| Another guy on this small team writes garbage code. Like "if
| (condition) true else false". He does have some redeeming
| qualities, but has caused huge amounts of bugs and tech debt
| despite being one of the most senior devs on the team.
|
| My code is not perfect, I've done the occasional bonehead
| maneuver and had dunning-kruger when I was young, but there is
| just no comparison. The majority of devs on this team are not
| shit; we know who the shitty ones are.
| xcv123 wrote:
| > not because the person who wrote it was incompetent.
|
| You haven't seen it yet. Some developers should be barred from
| the industry. Criminally incompetent.
| pjc50 wrote:
| In the words of Terry Pratchett, "It's indoor work with no heavy
| lifting". And it pays astonishingly well. Which are useful things
| to remember when it sucks a bit.
| Clubber wrote:
| A mentor once told me, "If you get frustrated, just go to the
| bathroom. When you are done, remind yourself you just got paid
| $10 to take a poo."
| bsenftner wrote:
| The last point is the most important one, last of course, as our
| industry does not respect communications, despite it being the
| main cause of all our irrational management deadline issues.
| r366y6 wrote:
| I couldn't agree more with this list. While I was at university,I
| used to imagine software engineering job like a place where like
| minded people talked all the time about algorithms,new
| technologies etc. A place where senior engineers would
| guide/mentor you, where you could take time to create the best
| code/solutions... :D For me, discovering that soft skills often
| are more valuable than tech skills was a huge wake up call.
| moffkalast wrote:
| Well it is kinda like that, if you have a software engineering
| job at a university lab haha. But even there there's usually
| heavy politics.
| skeedle wrote:
| The points in this article match what's in the book "Poems for
| Software Developers". https://www.amazon.com/dp/B0CMNR4G39 Like
| the article says, you'll probably not get a greenfield projects,
| you are going to spend a lot of times in meetings, and you aren't
| going to just be left alone to code. You will have to work with
| people on a team. Knowing the technical aspects of programming is
| one challenge, but another challenge is coordinating the effort
| of developers to drive to a goal, on time, and according to
| requirements. That coordination effort is a lot of what the
| experience working as a software developer is all about.
| deniscepko2 wrote:
| Mostly agree, but i think the more seniority you get in your
| company the less you will deal with these issues and of course
| changing jobs helps. So basically you might encounter all of
| these but not necessarily.
|
| And starting from scratch and college is basically the same point
| onetimeuse92304 wrote:
| 11. Perception is reality. Ideas mean nothing if you can't sell
| them. Providing actual value to the company means nothing if you
| can't sell it. You will work with people who cause more damage to
| the company than they bring benefit but are good at selling it.
| It does not matter what you think about what you are doing, it
| only matters what other people think. If you can be good
| technically and be a good communicator, the world is your oyster.
|
| 12. Most developers are very wrong about what would bring value
| to their managers. If you think you are underappreciated for your
| good work, there might be potentially very simple things that you
| could change that you aren't aware that could make you much more
| successful. Your manager might care less about how elegant your
| solution is but might remember you were two days late with it
| because he had to explain to his boss why the entire feature got
| delayed. Every situation is different and there is nobody on your
| team to help you -- you are responsible for reading the situation
| and making what is important.
|
| --
|
| And regarding:
|
| > 10) You will profit more from good soft skills than from good
| technical skills
|
| I would add more. You will profit more from learning _an
| orthogonal_ skill or field. You can be good developer by just
| being able to gather requirements and implement them. But you can
| be extremely valuable, sought after specialist if you know how to
| do those things AND ALSO know some other field not commonly
| considered by developers.
| Aeolun wrote:
| In regards to 12, there is a really good article out there
| somewhere about doing what makes your manager happy, not doing
| what he asks you to do.
| onetimeuse92304 wrote:
| Oh, agreed on that. I would say doing what your manager needs
| rather than what he/she asks you to do is a senior-level
| trick. You need to be experienced to be able to pull it off
| successfully.
| ibejoeb wrote:
| Absolutely. Become and expert in something, and then make
| software to solve problems in that domain. That's how you get
| rich.
| Tade0 wrote:
| I think college prepared me for some of those things.
|
| Group projects were a standard thing throughout most of my time
| there and they introduce you to the messiness of teamwork.
|
| I still recall one semester during which I was in two group
| projects with another guy and we negotiated who'll be slacking
| off and who pulling their weight in each of them so that everyone
| passes.
|
| One friend of mine is still holding a grudge against a mutual
| friend of ours who was extending the deadlines given to him to
| deliver his part until it was too late.
|
| I got top marks in a project where two guys just took over seeing
| that me and the forth guy were incompetent.
|
| I took one for the team when our lecturer said that he won't be
| giving top marks to everyone, so we need to decide who loses 20%
| of their points - I volunteered because I knew he personally
| disliked my choice of technology (NodeJS - we had complete
| freedom in that project with regards to platform/language) and I
| just needed to pass.
|
| Overall a learning experience.
| baz00 wrote:
| I'd just like to comment on these points on a 30 year
| perspective...
|
| Point 4 - incompetent people. They are great. When they fuck up,
| which they do often, you can save the day by simply being
| average. Just make sure people know that you saved it.
|
| Point 5 - meetings are great if remote. You can sit there muted
| on a zoom call for hours tweaking with your bike or playing games
| on your other computer.
|
| Point 6 - estimates are always wrong so don't put too much effort
| into it. What people value is how long you spend making up lies
| so spend some time on it!
|
| Point 8 - Uncertainty. Let other people handle that and hang
| themselves with it. That's what software architects are for. Be
| there to clean up the mess afterwards or at least complain about
| it.
|
| Point 9 - Eventually you do become able to disconnect from your
| job. One day the fucks just run out. Embrace that early on and
| save yourself a lot of stress.
|
| Point 10 - The only soft skill is politics. Any sufficiently
| large organisation employs many politicians. The best way to deal
| with politicians is analyse the factions and stay neutral. No one
| can drag you to their side then.
|
| There is a missing point though: objective one is getting paid.
| Anything else is secondary. If they stopped paying you how much
| of a shit would you give about all the other concerns? There you
| go now you understand. Nothing matters so don't get too wrapped
| up in it or upset about it.
| hardware2win wrote:
| >Point 5 - meetings are great if remote. You can sit there
| muted on a zoom call for hours tweaking with your bike or
| playing games on your other computer.
|
| You dont have to tell people about it...
| baz00 wrote:
| What is valued is presence and contributions. That doesn't
| necessarily require attention for the entire meeting. I'm not
| going to live forever so I would rather expend that wasted
| 80% on something that I value. The outcome of the meeting is
| always the same!
| nextlevelwizard wrote:
| Sounds like you are part of the problem
| baz00 wrote:
| Unlikely. I don't create meetings. I get invited to them.
| They are mostly unnecessary and have a net negative
| return of investment. I mean lucky if any of them have an
| agenda, minutes or an action and rarely does the
| facilitator actually have any conceptual knowledge of the
| subject. The meeting exists to service the facilitator's
| personal value and the naive process model, not the
| business, the staff or the customers.
| hardware2win wrote:
| Why just dont attend them?
|
| Im invited to like 10 of meetings each week
|
| Nobody expects me to attend those where im not really
| important or need to discuss stuff
| baz00 wrote:
| Because that means I have to justify not being a "team
| player" then. And I can't be bothered with that. I'm not
| creating conflict for the sake of it.
| nextlevelwizard wrote:
| Just stop attending then and do actual work and raise it
| up with whoever you report to. You are just as guilty for
| blindly accepting this behavior and then fucking around.
| Either do your job or do something else.
| benhurmarcel wrote:
| What problem?
| nextlevelwizard wrote:
| If you can't identify it, then you are definitely part of
| the problem
| sekai wrote:
| Managers forget to ask themselves if a slack message /
| email could have done it instead of creating ANOTHER
| meeting.
| nextlevelwizard wrote:
| And it is your job to tell them to go fuck themselves and
| stop wasting time
| Hamuko wrote:
| I've asked my coworkers to cancel a biweekly meeting that
| in my mind creates no value. That meeting still lives on,
| so I don't feel guilty about reading news or clipping my
| nails while it happens.
| matwood wrote:
| Have you asked what value they see in the meeting?
| Hamuko wrote:
| I think they decided to end the conversation there and
| then when I suggested axing the meeting, so I didn't
| bother. I just show up every two weeks muted and get
| noted as an attendee on some pointless meeting document.
| No skin off my back since I don't own equity.
| Tainnor wrote:
| Not GP, but I once asked my engineering colleagues if I
| was the only one who doesn't pay attention in the bi-
| weekly all-hands because most of the information is
| irrelevant to me (e.g. what new marketing strategies
| we're using). Some admitted that they would do some work
| on the side, but some also said "well, those people also
| want to have a chance to share what they did".
|
| I found this remark puzzling and illuminating at the same
| time. Apparently, for some people, meetings aren't about
| productivity but about satisfying psychological needs.
| teeray wrote:
| My retention from any audio is simply better if I'm doing
| something other than staring at the screen. On meetings that
| I've listened to while taking a walk, I can think back to
| specific things on my walk and recall exactly what was being
| discussed, sometimes months or years later. This holds true
| for doing housework, yardwork etc. There's some spatial
| component of memory that wakes up while I do that. It might
| look like I'm not paying attention to the meeting at all, but
| I'm actually paying _more_ attention and getting chores done.
| Win-win.
| nunez wrote:
| And you wonder why execs are pushing RTO so hard
| baz00 wrote:
| That's mostly because all that empty office space looks bad
| and it's worth nothing now.
| HunterWare wrote:
| So much truth in such a dense format. =)
| quickthrower2 wrote:
| I love that I work somewhere with no incompetent people (or
| rarely) as it makes working a lot more fun. You spend most of
| the day solving real problems.
| baz00 wrote:
| I had a couple of jobs like that. I looked back and worked
| out they weren't real problems. They were problems invented
| to sell solutions for that made money. Supremely productive
| but alas pointless too.
|
| I eventually developed a philosophy of passive capitalist
| nihilism. I can't change anything meaningful so I will use
| the accumulation of capital as a coping mechanism to deal
| with that.
| quickthrower2 wrote:
| There are no "real" problems if you have water food and
| shelter and your family and friends are safe etc.
| Everything is consumerist driven. Driven by desires.
|
| But my current job they are building something worthwhile
| and I believe a lot of companies are. But the FAANGs might
| feel less like that. But let's say you work for Splunk or
| Shopify or a government portal or writing drone software or
| whatever I think it is useful.
| BurningFrog wrote:
| Desires are real though.
| ljf wrote:
| That is how I feel in my current team/department - but I
| always worry that if you don't know who the incompetent
| person on a team is...
| quickthrower2 wrote:
| That is why I hanker and breed plenty of imposter syndrome
| :-)
| loeg wrote:
| It happens sometimes! I've been there. Enjoy it while it
| lasts.
| mk89 wrote:
| Thanks for sharing your valuable point of view. Unfortunately
| TV shows, media and being a nerd at home while everyone else
| was having fun created the myth of the brilliant software
| engineer that is saving the world through coding - in some
| cases it was therapeutic or a way to be "different".
|
| Reality is that the software industrialization (which happened
| after 2000 I believe?) didn't give a damn about those nerds or
| 10x engineers or whatever: they want decent people that can be
| replaced as needed. Not necessarily in a cynical way but in a
| way that every other field works - employees should not become
| a risk. When that happens, you as a manager have failed
| miserably.
| baz00 wrote:
| Yes that's a fair perspective. They wanted fungible staff.
| The only way to add personal value is to be as non fungible
| as possible which means being an expert on niche things that
| the fungible folk aren't. That is usually domain specific
| concerns and intricacies.
|
| But really I haven't changed the world. I've made it a lot
| worse. I caused the loss of thousands of jobs. I took money
| from bastards and con men in return to make things to make
| the world worse. I celebrated the demise of competitors and
| their staff going hungry.
|
| And I only did this all because my official qualification
| didn't pay as much.
|
| At least I'm honest.
| Guid_NewGuid wrote:
| You've obviously hit a sore spot for some people.
|
| The system is built to capture value (not create it) while
| externalising as much damage and cost as possible.
|
| The sooner one accepts that the less deluded one needs to
| be. There's no company 'mission'. The only mission is try
| to find a way to survive and prosper under hegemonic
| capitalism.
| munksbeer wrote:
| > The system is built to capture value (not create it)
| while externalising as much damage and cost as possible.
|
| What system?
| FrustratedMonky wrote:
| The System. US. We are MOLOCH.
| nerdponx wrote:
| It's worse than "the system". It's natural human
| behavior. Take as much as you can for yourself and your
| friends/family, push the costs onto everyone else.
| Altruism only happens in proportion to the extent to
| which it's felt.
|
| Humanity has not yet invented a system that discourages
| this behavior effectively in the presence of abundance
| and wealth.
| sevensor wrote:
| > The only mission is try to find a way to survive and
| prosper under hegemonic capitalism.
|
| How true this is depends on where the money is coming
| from. Founders at a bootstrapped company may actually
| believe in their stated mission. I've seen it. Once
| investment money gets involved, sure, it's all about the
| exit. Even the founders may be legitimately confused
| about this, which results in a lot of mixed messages.
| Professional leaders who have held executive positions at
| large enterprises have zero illusions and will probably
| give it to you straight if you ask them one-on-one.
| ptero wrote:
| That is a choice. Not criticizing you for yours (and bonus
| points for honesty), but optimizing for money is not the
| only game in town. Plenty of software engineering work
| makes the world better while paying enough for a very
| comfortable life. Not FAANG levels, but good money. My 2c.
| baz00 wrote:
| Yes I agree. I don't make FAANG money but I live
| comfortably. I think what is important is optimising for
| a fair balance of happiness in life, which despite my
| negative outlook here is pretty damn high and taking home
| enough cash to enable you to do what you want to do
| before you drop dead.
|
| I'd be more invested in something which improves the
| human condition but that's a 1 in 100,000 job. Perhaps I
| should have done biochemistry or something at university.
| firejake308 wrote:
| Hey, if it makes you feel better, a lot of biochemistry
| research ends up being completely meaningless fluff that
| is only published to inflate the author's reputation, but
| will likely have zero effect on the real world.
|
| You can be cynical about anything if you want to :)
| baz00 wrote:
| Hahaha thanks for the perspective. I feel a little better
| now at least :)
| aleph_minus_one wrote:
| > I'd be more invested in something which improves the
| human condition but that's a 1 in 100,000 job.
|
| I think the ratio is _much_ larger.
|
| But consider that market forces _do_ work:
|
| Since a lot of people want to do such a job, the salary
| will be quite low (i.e. so low that there won't be a long
| queue of people who want to do the job for such a low
| salary; the salary will just be high enough that the
| positions can be filled), thus these jobs will typically
| only be attractive to people really who want to put their
| money where their mouth is (i.e. their willingness to
| improve the human condition is so huge that they are
| willing to accept such low salaries).
|
| On the other hand, the salaries of "bullshit jobs" or
| jobs where you do evil things will be much larger,
| because otherwise the company will have difficulties
| filling the positions.
| FrustratedMonky wrote:
| Disagree there is a choice.
|
| We all have money pressures. It is ALL MOLOCH.
|
| If you think you have a choice, then count yourself lucky
| that your life ended up in a position that allows that
| illusion.
| JohnFen wrote:
| This. I've learned that I can't optimize for income,
| because typically it means I'll be doing work I dislike,
| or working for a company I dislike. For me, there is no
| amount of money that can balance that out. I'll prefer a
| position that pays a bit less but that I enjoy over one
| that pays excellently every time. To do otherwise ensures
| I'll have a miserable life.
|
| Others can and do differ, of course. We all optimize for
| what's important to us.
| benterix wrote:
| > At least I'm honest.
|
| For what is worth, I appreciate this last bit and I think
| many others do, too. It's depressing to see a person doing
| all these things and not seeing through this.
| throw4847285 wrote:
| Your grandiose language (I've seen things you wouldn't
| believe, etc.) means you aren't as self-aware as you think
| you are.
| baz00 wrote:
| Sorry I didn't think past listing the horrible things I'd
| done. Perhaps I should have stuck my business hat on and
| gone a bit more _Cervantes_ to fit the mould of startup
| culture?
|
| _" One man scorned and covered with scars still strove
| with his last ounce of courage to reach the unreachable
| stars; and the world will be better for this."_
|
| Urgh no I'll stick with reality.
| throw4847285 wrote:
| That's Cervantes? I thought it was by Leigh and Darion.
| It's possible that they adapted a real (translated)
| Cervantes quote for a song in Man of La Mancha, but a few
| Googles don't yield any trustworthy sources that
| attribute the quote to Cervantes himself.
|
| In any event, Brian Stokes Mitchell did a phenomenal
| rendition: https://www.youtube.com/watch?v=zbgTUwUP-ew
|
| Wait, this is the Broadway World forum, right?
|
| Edit: Yup. Confirmed with someone with a doctorate in
| Spanish Lit and a deep love of Cervantes. That quote was
| invented for the musical. Oh well.
| bluetomcat wrote:
| A "nerd" will be under-utilised and probably dissatisfied in
| most companies. Most software projects require developers
| with a level of knowledge that is "industry standard" - being
| able to write good-enough code in a popular language/stack
| with a popular IDE and tooling used in a company-specific
| way. Nobody would care about your vim customisations, the
| lock-free data structures you implemented, or your deep
| knowledge of compiler optimisations.
| kevindamm wrote:
| I think this is spot on and that distinction deserves to be
| in the education of present and future programmers. It's at
| the root of the different terms (programmer, SWE, computer
| scientist, developer) and it's not unusual for a role to
| demand more than one of these types of behavior. But, it's
| often disheartening to those who would rather spend their
| time daydreaming in math.
| bell-cot wrote:
| > Unfortunately TV shows, media and being a nerd at home
| while everyone else was having fun created the myth of...
|
| Well, yeah. But how many _real_ careers are accurately
| portrayed in TV and media, or closely resemble doing $Stuff
| as a hobby? I 'm thinking somewhere between "zero" and "Gell-
| Mann Amnesia".
| golergka wrote:
| > Reality is that the software industrialization (which
| happened after 2000 I believe?) didn't give a damn about
| those nerds or 10x engineers or whatever
|
| That's only true for 95% of companies, not 100% of them. But
| if you're really in the 5th percentile, you shouldn't care
| about these 95% anyway. I've been lucky to experience
| software companies that really care about exceptional
| engineers (and have proper business incentives to do so), and
| it truly has been the best place to work at as a software
| engineer.
| hoagsobject wrote:
| >estimates are always wrong so don't put too much effort into
| it. What people value is how long you spend making up lies so
| spend some time on it!
|
| Why people always say this? In my team we have never missed an
| estimate of what we have planned. I also don't remember it in
| other projects where team does take time for planning. What is
| so hard that people find estimating their work?
| Clubber wrote:
| You can make any deadline if you pad enough.
| matwood wrote:
| Which, when you ask enough questions, is what most
| stakeholders want.
| creshal wrote:
| Unless the budget is limited, and estimates have to be
| "optimized" to meet political goals. At that point,
| disengage and waste as little time as possible on making
| up shit.
| pbmonster wrote:
| Careful, available budget will always be spent, available
| time will always be filled.
| not_the_fda wrote:
| Sometimes the spec of wants to be built is just some notes on
| a napkin with a whole lot of ambiguity.
|
| Sometimes the "estimate" was already predetermined to meet
| some arbitrary marking goal.
| baz00 wrote:
| It's easy on small teams on small products. Eventually, as
| capitalism demands eternal growth, they grow to the point
| that the complexities and hack jobs that were used to deliver
| previous estimates impact them. Then no one wants to turn up
| with a realistic estimate. Eventually all the estimates
| become lies because of the incalculable complexity of the
| estimation process that results from the complexity of the
| product and your options are usually to try and lie and
| deliver late, but not later than other teams in the org.
|
| Every org I've worked for ends up like this.
|
| There is a lot or intellectual dishonesty out there. It used
| to bother me. It doesn't now. I just don't partake in it.
| jefc1111 wrote:
| Maybe you are getting good quality requirements and / or have
| a system to work on that is somewhat easy to reason about.
|
| Requirements are often hazy. Pushing back on that is good,
| but if the response is "do it anyway" then you either quit or
| handle the uncertainty as best you can. The latter makes
| estimating hard.
|
| If you are going to have to depend on third parties (whether
| internal or external) that is another thing which can torpedo
| an estimate that was made in good faith. There would often be
| too much uncertainty in that situation to be able to
| accurately account for it in an estimate.
|
| "estimates are always wrong" is obviously an exaggeration -
| the whole comment is written in that spirit.
| grujicd wrote:
| Are you always working on similar projects? Unknown unkowns
| are what gets you.
| azangru wrote:
| > What is so hard that people find estimating their work?
|
| Unpredictability for any new work. Even knowing my codebase
| well, I sometimes forget how changing some piece of code will
| require changes in other places. And without having done
| exactly the same work before, I cannot know how difficult it
| will be and how long it will take.
|
| Dependency on other teammates or other teams. If another team
| is building something that your work depends on, you have no
| way of knowing when you'll be finished. If the code you write
| needs to be reviewed by other team members, and then you'll
| have to incorporate the suggested changes, this makes it
| harder for you to say how long something will take.
| aleph_minus_one wrote:
| > What is so hard that people find estimating their work?
|
| The central difficulty and huge part of many programming
| projects is actually the "unknown stuff" that is insanely
| hard to estimate, be it
|
| - requirements set up by users are often very vague
|
| - interacting with some very complicated third-party
| library/software that takes years to only understand the
| basics of
|
| - many programming tasks are unique, thus you have never
| implemented anything remotely related, and thus also have
| hardly any idea where the difficulties might lie
|
| - the new software "has to behave like the old one". In the
| old software, there exists an insane amount of corner
| behaviour where nobody has any idea why it was introduced,
| but the users will at some point complain if the new software
| behaves only a little bit different in such an obscure corner
| case
| JohnFen wrote:
| > The central difficulty and huge part of many programming
| projects is actually the "unknown stuff" that is insanely
| hard to estimate, be it
|
| This is my observation as well.
|
| I also think that devs tend to consider the central problem
| they're solving when estimating, rather than the totality
| of the work that has to be done in order to complete a
| task. If I'm tasked with adding a new feature, my mind is
| focused on the business logic of that feature and if you
| ask me how long it's going to take, I'll tend to answer the
| time for just that. I'll tend to forget the time required
| for all the other ancillary work around that
| (documentation, UI changes, code review, QA, etc.) Omitting
| that stuff results in wildly optimistic estimates.
| icedchai wrote:
| Some problems I often see: 1) The people
| estimating the work aren't always the ones doing it.
| 2) Engineers are optimists, estimates are often best case.
| 3) Not enough padding added to estimates (see #1 and #2.)
| onethought wrote:
| I think it depends on industry, maturity of team (tenure on
| that project).
|
| I've worked on teams that have exactly your experience. I've
| worked on others where they could just never hit the mark.
| Skills and experiences seemed equivalent. There didn't seem
| to be a magic bullet reason, just a whole series of
| reasonable explanations.
| JohnFen wrote:
| I'm amazed to read this. I'm pretty sure that I've never seen
| a reasonably accurate estimate for a nontrivial task in my
| entire career.
| gilbetron wrote:
| "we have never missed an estimate"
|
| After 35+ years of software development, you are either
| lying, incompetent, or worked on exceedingly trivial
| software. Sorry to be harsh, but I can guarantee you that if
| you were given a significant software project, asked to
| estimate and then deliver, that the vast majority of the time
| your estimates would be wrong.
| JohnFen wrote:
| They could also be greatly padding their estimates. When I
| estimate things, I take the amount of time I think it will
| require and double it. In my businesses, my partner would
| take my padded estimate and quadruple it. By doing that, we
| never blew past a deadline promised to a customer. That
| doesn't mean the estimates were accurate -- if they were,
| no padding would be necessary.
| tensor wrote:
| For sure, some teams are way better at estimating than
| others, and I don't think it helps when a team has the
| attitude that estimates are some sort of corporate bullshit.
|
| No other engineering discipline has this level of immaturity.
| Sure, estimates in other industries are also notoriously
| hard, but you don't see this utter disregard for them you see
| in software. And, I bet you donuts that every "software
| engineer" here as demanded estimates from other fields and
| felt angry when they were missed.
|
| "When is that bridge going to be finished?" "When is the road
| work going to be completed?" "When is my house renovation
| going to finish?"
|
| Estimates are important. And yes, they are hard, but there is
| spectrum of skill levels at doing them well.
| JohnFen wrote:
| Outside of HN commenters, anyway, I don't think I've
| encountered a dev that doesn't understand the importance of
| estimates and that thinks they're nothing but BS. Most make
| honest attempts at accurate estimation.
|
| However, most devs I've worked with were also very aware
| that estimates themselves have such a large margin of error
| that they can be considered a bit bullshit even though they
| are necessary.
| manicennui wrote:
| At most companies the stakeholders barely know what they
| want. They provide a vague idea of what they want, and you
| give a wild estimate (referred to as a Silly Wild Ass Guess).
| Knowing all of the details of the problems that one is going
| to encounter in their old legacy system is basically
| impossible without spending a bunch of time up front, and you
| always discover more when you start writing code, so it is
| best to just start and iterate until you have enough of what
| the stakeholders want and you move on to the next disaster
| project.
| jefc1111 wrote:
| I don't think all of this applies in a small outfit. Some of
| it, sure... Politics is less of an issue in smaller companies.
| Disconnecting is perhaps actually harder in small companies,
| idk. Incompetent people can't easily find a place in small
| companies I reckon, unless, unless everyone is incompetent, in
| which case the company won't be around for long!
| baz00 wrote:
| Fair points there. Although I have worked for a number of
| very small companies (startups) that have been successful and
| totally incompetent, at least one to the order of having the
| CEO threatened with jail time by the authorities.
| eschneider wrote:
| If anything, politics is MORE of an issue in smaller
| companies, but it usually plays out differently. Be aware of
| what's going on and _be involved_ or prepare to get
| blindsided at some point.
| alphager wrote:
| Strongly disagree. The smaller the company is, the more
| political it is. Because now there's no layer to appeal to or
| to inject sanity; it's the way of the owner or the highway.
| Being on the right side of the owner is the most important
| thing and if you're on the right side, you can be as
| incompetent as you want (see: son of the owner is an idiot,
| but is the second in command).
| dasil003 wrote:
| Sorry you've been burned by nepotism and incompetent
| leadership. That's not the root of politics though.
| Politics is about decision making processes and power
| dynamics that emerge in large groups. This becomes
| difficult regardless of competence because power and
| control become decoupled due the bandwidth limits of single
| humans, and so the methods of influence and direction
| become more manipulative and/or more draconian.
| jefc1111 wrote:
| Maybe you're right. If so, I guess I am one of a lucky
| minority that buck the trend!
| red-iron-pine wrote:
| depends on the small org. large orgs have a lot of people and
| a lot of personalities, processes, HR handbooks, you name it.
|
| small companies have a handful of people, and if there is a
| clash then you're gonna have a bad time. in some ways this is
| good since you have only to lever or negotiate with 2-3
| people, and can get facetime, but if you're on the shit-list
| it's not gonna happen.
| jefc1111 wrote:
| You make a good point. There have been times an HR handbook
| / department would have been useful. At the end of the day
| it's a choice I guess, which kind of org you work in. HR
| departments can also be a bad presence, depending on what
| is going on for you at the time.
| barelyauser wrote:
| Point 10: don't this makes you a target? Being part of the
| tribe might be painful, but getting thrown into the jungle
| alone is a hell of a lot worse.
| creshal wrote:
| It makes you a target if you position yourself as a faction
| of one that tries to influence decision making. That's a
| contest you're not going to win, 99% of the time.
|
| If you just go with the flow, and are reasonably competent,
| changes in faction dynamics usually wash over you. You end up
| taking orders from someone else, every now and then, but if
| blame needs to be pinned on someone, there tend to be juicier
| targets.
| baz00 wrote:
| Exactly that.
| orwin wrote:
| No, if you're competent and have good soft skills, you can
| survive a purge even if you did not take a side.
|
| I was hired at my previous job by a departing manager who
| just lost his struggle against our new manager. I managed to
| finish my job, extend the solution to other teams (as mine
| went from 12 devs, a handful of Indian support, an Indian QA
| and PM, to a dev and two level2 support). It was probably my
| most painful job yet, I regressed, I didn't really 'finish'
| in the sense that it lacked documentation, good CD pipeline
| and minor tweaking to make it more efficient, and I hated the
| last months with my whole being. But politics didn't touch
| me.
| paganel wrote:
| > Nothing matters so don't get too wrapped up in it or upset
| about it.
|
| The "it is what it is" way of looking at things, I wish more
| people in this industry would embrace this.
|
| It more probably won't get one to 600k yearly comps while
| working at FANGs, but at the same time is a lot more healthy
| for one's psyche in the medium to long term (and for the
| psyches of those close to that person, like family and very
| close friends).
| demondemidi wrote:
| Here's my one key observation after 35 years:
|
| Whenever someone refers to planning as "lies" and whines about
| "politics" ... you can be sure they are a difficult person who
| blames everyone but themself.
| baz00 wrote:
| I think you'll find I blame myself for these issues. I just
| do not deny that they are issues.
| Wilya wrote:
| I blame everyone else and myself equally.
|
| But I'll stop whining about politics when I'll stop
| witnessing well-behaved but incompetent people turn projects
| to failures.
| benterix wrote:
| > Whenever someone refers to planning as "lies"
|
| I believe it's all about size. Small tasks can be estimated
| fairly precisely, with 30% margin maybe. But some people
| extend this logic to huge projects and this simply doesn't
| work.
|
| I give you example: I was once asked to estimate the amount
| of work needed to migrate a huge org from on-prem to one of
| the public clouds. Without even knowing what kinds of app
| they were running. I said I can only do a very rough estimate
| and there are too many variables to be precise. But they
| insisted and hired someone else to do this job with the
| precision of half-day!
|
| Needless to say, their estimates were too optimistic because
| they could only include what they knew. By design, they
| couldn't measure the things they know nothing about because
| these issues haven't appeared yet. Last time I checked, they
| are still migrating and I have a feeling they will finish
| around the time I had originally planned, that is the second
| quarter of 2024.
| martincmartin wrote:
| When you estimate small tasks, most of the estimates will
| be accurate, but once in a while, you'll overlook something
| and a small task turns into a big task, e.g. you need to
| switch APIs or the customer wanted something that sounded
| similar but turns out to be much more complicated under the
| hood. So it's not a Gaussian distribution, it's that once
| in a while a task blows up.
| broast wrote:
| In my experience, large estimates are only ever Rough
| Orders Of Magnitude. Our teams do not pull any work in to
| be done unless they've broken it down to the smallest
| estimated components. Anything with a large estimate is
| inherently inaccurate and not ready to plan around.
|
| The situation you described seems quite broken
| olddustytrail wrote:
| So you're saying you didn't get the job and the people who
| did are getting paid a lot more than they originally bid?
| :)
| benterix wrote:
| No, I quickly moved to another team and watched my
| colleagues get fired or quit one by one as they couldn't
| keep the estimates done by someone else under pressure.
| It was a surreal experience.
| mytailorisrich wrote:
| Acknowledging the ubiquity of politics in organisations is
| not whining. He only offered a way to deal with it for those
| not interested in playing the game, or who are not very good
| at it.
| fra wrote:
| "politics" just means "large groups of people making
| decisions together". People love to complain about it, but in
| reality it is the one tool we have to steer large
| organizations.
| red-iron-pine wrote:
| "once God crapped out a 3rd caveman a conspiracy was
| hatched"
|
| You can't have large groups of people making decisions
| without politics, and anyone saying otherwise is kidding
| themselves. You either play the game and pick a side, or
| someone picks it for you and you get what you get.
|
| Keep in mind this is entirely separate from ruthlessness or
| backroom deals; this is just the way of things with large
| groups of people.
| jyounker wrote:
| The poster is referring to estimation, which is different
| than planning. Estimating is hard, and requires a many people
| working together. It can be done for a group, but not for
| individuals.
|
| In many places estimates are actually lies. There are even
| plenty of companies where realistic estimates, and well
| planned projects will get you sidelined. These are often
| places that reward for fire-fighting rather than planning,
| and where your value is judged by how busy you appear to be
| rather than how efficiently you work.
|
| It's important to understand which kind of company you are
| working in, and if you understand that, then you can adjust
| your behavior appropriately, and succeed within the
| environment.
|
| I'm happy to be working in a place that rewards for planning,
| but I've worked in places where detailed and accurate
| planning was punished. Oddly enough, this division is
| surprisingly disconnected from whether the business is
| successful or not. A good business model will cover a
| multitude of technical sins.
| konschubert wrote:
| Wow I'm sorry, it seems like you really had a bad experience.
| baz00 wrote:
| I had good ones too. But they didn't pay as much.
| strikelaserclaw wrote:
| Here is something i encountered, sometimes higher ups will put
| arbitrarily deadlines and act like the entire business depends
| on you meeting that deadline for a project and after that
| deadline passes no one seems to care that much about your
| product, they even allow you more time to do it "right".
| psiops wrote:
| That some top-tier management practices you experienced
| there. I expect your productivity*quality sky-rocketed.
| datadrivenangel wrote:
| Spanish theory of management! The more they push the more
| they get!
| aleph_minus_one wrote:
| > Point 10 - The only soft skill is politics. Any sufficiently
| large organisation employs many politicians. The best way to
| deal with politicians is analyse the factions and stay neutral.
| No one can drag you to their side then.
|
| Staying neutral does not only have the meaning "be diplomatic"
| or "don't give an opinion", but can also mean "treat all
| factions _equally_ ", which includes the case "treat all of the
| people who make political attempts with open hate". This way,
| also no one can drag you to their side. :-)
| baz00 wrote:
| Definitely correct. I'm glad you extrapolated that point.
| cj wrote:
| Whenever I see comments like this I feel bad for the commenter.
|
| For all the opportunity and different companies to choose from
| in tech, to not enjoy your job after 30 years probably means
| you picked the wrong career path. It's not healthy to have this
| much disdain and displeasure around your work.
|
| It's never too late to consider a career change.
| andygeorge wrote:
| Agreed. I'm "only" 20 years into my career and, while it has
| ebbed and flowed, it's also something I love and am thankful
| I get to do for a living.
| subjectsigma wrote:
| They might just have a different perspective than you. I
| complain about my job a lot. People say to me, "Wow, you must
| absolutely despise it." The truth is that if I absolutely
| despised it I would have left a long time ago. I just have no
| reason to talk about the good parts. I focus on problems
| because I want to improve on them.
| deebosong wrote:
| > I focus on problems because I want to improve on them.
|
| Does this work, though? Does the complaining lead to
| improvements?
|
| I'm posing the question as a challenge, and also out of
| curiosity. And I'm of the school of thought that it's
| necessary to acknowledge reality, but, complaining to the
| point where people think I despise what I'm complaining
| about may indicate that another approach may be necessary
| (such as finding practical solutions and giving yourself
| options that you can test out).
|
| Apologies if being presumptuous.
| subjectsigma wrote:
| It's probably different for every person but complaining
| about my job either helps me arrive at a solution or
| realize that I can't do anything about it and distance
| myself. I'm very lucky to have never been in a situation
| yet where the problem is unfixable, truly unbearable, and
| I also can't just leave.
| felipellrocha wrote:
| Came here to say the same thing, but a lot more angrily and a
| lot less eloquently. Thanks!
| jaipilot747 wrote:
| Maybe... But isn't your view also very dismissive of their
| experience and the constraints and context of their
| experience?
|
| By far, most companies above a certain size do not operate in
| a way where these principles do not apply.
| aleph_minus_one wrote:
| > It's never too late to consider a career change.
|
| Absolutely, but the huge difficulty is finding a place where
| the grass is greener. Nearly the whole world is quite equally
| shitty, it is just the kind of shit that you will see at the
| various careers ("septic tanks") differs.
| ThrowAway1922A wrote:
| I'm not that guy, but I don't have to like it. I'm not
| skilled at anything else and I couldn't make this much money
| in any other career.
|
| Most people will never enjoy their work, but I can dislike my
| work while being far better off than most people ever will
| be.
| emanuele232 wrote:
| harsh reality is that 80% of humanity works a dead-
| end/awful/not wanted job just because bills. IT is a nice
| bubble in which you do something you are mostly passionate
| about and you get paid well. I'm not saying "we got it good
| so don't complain" but sometimes is worth to analyze the
| situation from the perspectivo of an outsider. IMO i can do
| whichever tech job, the more i dislike it the more i need to
| be paid, that's all
| antifa wrote:
| Pretty much any job I might have enjoyed more, if it's not
| a lot of fancy words for "become a celebrity", will look
| like minimum wage compared to software engineering. Even
| when it doesn't, pre-AI software engineers were
| aggressively stalking around the corners of dark alleys to
| cut the wages/number of seats of that job.
|
| Most other lines of work guarantee poverty or are a riskier
| gamble with worse prizes and worse loses.
|
| You want to be at the top of the titanic looking down at
| those swimming to what's left of the upper deck, not
| rearranging chairs seconds away from being underwater.
| mytailorisrich wrote:
| No, this is being realistic. Time makes the rose tinted
| glasses go away.
|
| This would be the same with another career.
|
| It doesn't mean he does not like what he does, just that he
| sees the reality of working in an organisation.
| JohnFen wrote:
| I don't know. I've been doing this for over 30 years and
| that seems far more cynical to me than realistic.
| hello_moto wrote:
| I've been doing half of yours and I found that the advise
| is more realistic and I'm doing exactly all the points he
| listed but still love my job.
| cynicauliflower wrote:
| To some extent presenting a cynical affect is seen as
| intelligent, or "cool". The poster claims they like the
| work, so I'd just take them at their word.
| baz00 wrote:
| At no point did I say I don't like this. It's absolutely the
| best career I could think of. No heavy lifting, no dealing
| with bodily fluids or excrement, no harsh weather conditions,
| low to no risk of getting killed, no dangerous chemicals, no
| being shot at etc. And I get to play with things all the time
| and solve interesting problems.
|
| But it is what it is!
| onethought wrote:
| Right, but you are cynical and dispassionate. There is a
| world you could be working in a place where you are more
| passionate and less cynical.
|
| (This could be more personality than experience though, so
| I agree it could be a misread)
| baz00 wrote:
| I am passionate about the things I'm interested in, not
| all the unnecessary fluff around them :)
| d4mi3n wrote:
| Not everyone needs to be passionate about the day job.
| Being present, competent, and reliable is enough. I'd
| personally go on to say that it's risky to put too much
| emotional investment into something you don't
| own/control.
|
| I prefer to invest my passion in things outside of my day
| job. Working is fine, but it's a means to an end to fuel
| more meaningful things. We don't live to work.
| pseudoramble wrote:
| "I'd personally go on to say that it's risky to put too
| much emotional investment into something you don't
| own/control." Bingo! This is exactly what happened to me.
|
| What I learned is that, even in a great environment where
| there was a ton of latitude to have ownership of
| technical details and even product details, it's still
| contained within the broader context of a business. That
| business has interest in the thing you're working on
| while it's a factor in creating value, and when it
| becomes time to change focus onto other things, it will
| generally do that without much hesitation.
|
| I've been burned by this multiple times. Eventually it
| clicked for me in the way you phrased it. So I show up
| and do what I can, bring my expertise as much as I can,
| gauge where the limits of what I can provide are, and
| keep a healthy distance mentally otherwise.
|
| One other note - you can still be passionate about
| software and not one specific day job. You can still work
| on other projects and explore ideas as much as you want.
| It's just that that's a separate thing from work.
| Dedicate time and space separately for that IMO.
| jyounker wrote:
| After 30 years in the job, I say that the poster you're
| responding to is just realistic. I love my job. I love
| what I do, but it's worth remembering that it's just a
| job. There is so much more to life.
| sbarre wrote:
| Amen to that. Work to live, don't live to work.
| broast wrote:
| To say it's "personality" is a little passive
| aggressively degrading. These opportunities are not
| accessible or sensible to everyone all the time.
| onethought wrote:
| I think you misread my intent. I was saying it could be
| personality of cynicism (which is fine) and nothing to do
| with the job.
| ijot490mp wrote:
| To me it seems that the OP can think for himself and he
| knows how to be productive. And what he describes is not
| cynical but realistic in my opinion. He knows what he
| wants and how can achieve that. I would take such a
| "cynic" on any day over an overzealous overjoyed empty
| headed happily clapping indoctrinated droid TBH.
| anon291 wrote:
| > There is a world you could be working in a place where
| you are more passionate and less cynical.
|
| The idea that if you're passionate about something you
| won't have any complaints about it or enjoy it 100% of
| the time is unhealthy. Most people realize that there's
| always an element of 'grind' to any task. You could be
| the most passionate person in the world, but I can
| guarantee that something about your passion will annoy
| you slightly. That's just being human
| onethought wrote:
| I don't disagree. Sorry I feel people have misread a lot
| more malice into my comment than I intended.
|
| I felt sympathy for the OP not superiority.
| j_french wrote:
| I didn't pick up disdain or displeasure from your original
| message, and I didn't feel bad for you. I felt good for
| you! I thought "here's someone like me, who's making a
| decent living in a nice job, but who has a good sense of
| perspective and isn't getting caught up in the inane
| irrelevant trivialities of the tech workplace that are
| ultimately utterly meaningless." You can make a living
| doing something you enjoy without having to buy into every
| single aspect of a corporate workplace and without tangling
| up your identity with your job. Some of us work to live,
| and are happy doing that. It's not a failure to be not
| totally consumed with your career.
| bumby wrote:
| Tbf to u/cj, there's a few things you mentioned that would
| lead one to believe you aren't fulfilled with your job
| (which, I think, is an important distinction from being
| 'happy' with one's job).
|
| If 'objective one is to get paid' it comes across as
| primarily a monetary transaction. That's generally not how
| the people I know who are really fulfilled in their careers
| look at it. Sure, pay is an important part, but they also
| really value aspects like a sense of purpose, the
| camaraderie of working on a good team, and being able to
| meaningfully contribute, amongst others.
|
| "One day the fucks will run out." You say this as a point
| about disconnecting, but you can disconnect while still
| "having fucks" about your job. Your life doesn't have to
| revolve around your job, but I don't want to work with a
| bunch of people who don't really care about what they are
| doing.
|
| You talk about how you spend remote meetings doing other
| not-work-related things. I get that meetings can be boring
| or of little value at times. In those times, ideally, I
| would prefer someone be honest and say the meeting is of
| little value and go do something more productive. At the
| least, I would like them working on something of value to
| the group while occasionally checking in. You wouldn't act
| this way in person, so I don't understand why you think it
| would be ok to do so remotely, other than it's because you
| can get away with it. Again, that makes it more
| transactional than contributory.
|
| I could go on with the other points, but all that is to
| say, I don't think u/cj was completely off with their
| comment.
| dasil003 wrote:
| I was going to make the same points. Some of these are
| frustrated and cynical dismissals that may represent
| reality sometimes, but are counterproductive when taken
| axiomatically.
|
| For instance, "estimates are lies" fails to acknowledge
| that planning must still be done in the face of
| uncertainty, and engineering is the best equipped to do
| this. The last thing you want is for the pointy hairs to
| just start pulling deadlines out of thin air. But
| recognize it's not about putting in time, it's about
| helping the business plan and setting up the team to
| build things the right way. If you do this well, everyone
| wins, but it does require the ability to work smoothly
| with people who don't share your same expertise and not
| treat them like idiots.
| codr7 wrote:
| Planning doesn't mean estimation though; we all know it's
| just guesswork, and basing business decisions on
| guesswork is madness. On top of that it's a lot of wasted
| time and effort.
|
| Milestones and projections is a much more constructive
| approach, simply tracking the number of tasks in your
| backlog over time will give you an increasingly correct
| projection of when the project will be finished.
|
| https://www.youtube.com/watch?v=QVBlnCTu9Ms
| dasil003 wrote:
| Very good point, planning is a broader activity than
| estimation. I find people bring a lot of baggage to the
| idea of estimation, like in this case you say "it's a lot
| of wasted time". There's an assumption in there somewhere
| about what constitutes an estimate. If you're talking
| about an eng-week granularity estimate for a project that
| is going to take 6+ months then absolutely I agree with
| you.
|
| But for me an "estimate" is just a sense of the level of
| effort required sufficient for the needs of planning at
| the time. It goes hand in hand with risks, dependencies,
| and other assumptions that need to be kept in mind. The
| exact form of an appropriate plan depends a lot on the
| business constraints like how delivery timeline interacts
| with customers, external events, and the broader
| ecosystem that the company operates in.
|
| As for your suggested backlog approach, this makes sense
| if the requirements are rigid and accuracy on the
| delivery timeline is the most important thing. This is
| situational, but in many projects I've led, the scope is
| negotiable, and therefore important to keep the big
| picture in mind to find opportunities to refining or
| consolidating scope. A common anti-pattern I've seen when
| relying on ticket/task-level tracking is the team missing
| the forest for the trees. It's possible to leverage these
| systems to support high-level planning, but I tend to
| prefer documents or a simple spreadsheet gantt for that
| purpose, and use ticket/task tracking for last-mile work,
| intakes, bugs and other inputs that we don't want to lose
| track of, but may vary widely in their importance and
| relevance.
| bumby wrote:
| To your point, most planning is bad. That doesn't mean
| planning is worthless when done right. It seems that most
| bad planning fundamentally misses the interactions
| between different tasks (ie it largely treats the
| different tasks as independent). A probabilistic approach
| that correlates the tasks seems to work better.
|
| Sometimes estimates are made out of ignorance or borne
| from an optimism bias. But sometimes they are lies,
| because its easier to get a project funded based on a
| misrepresentation, and keep it funded once the initial
| cost is sunk.
| codr7 wrote:
| The point is they're always guesses, so we multiply by Pi
| or whatever to make reasonably sure we're not coming up
| short. But it's all a game, and everyone knows deep down
| inside that it isn't working.
| bumby wrote:
| > _they 're always guesses_
|
| Maybe it's so prevalent in SWE that most are jaded, but
| all it means is that we are pretty bad at modeling it or
| simply don't care. Other domains, like aerospace, have
| similar problems but have much better methods to arrive
| at more reasonable estimates (when they care). For
| example, [1] gets into joint cost/schedule estimating
| using a more data-driven method where you can put
| uncertainty around it. It certainly beats 'multiplying by
| pi.'
|
| [1] https://www.nasa.gov/ocfo/nasa-cost-estimating-
| handbook-ceh/
| codr7 wrote:
| Comparing to physical engineering doesn't make much sense
| to me.
|
| Part of the problem is it's all virtual, so there are no
| limits; part is that we're always pushing the envelope in
| the complexity department.
|
| Building the same software again with just a tweak or two
| doesn't happen very much, the reason we build new systems
| is often to try something so different that it's not
| feasible to adapt existing systems.
|
| Most of the time we have no idea exactly what we're
| building until we get there, even the customers usually
| have no idea exactly what they want.
|
| Imagine going to a car manufacturer and giving them the
| kind of specifications we usually get for software, I can
| assure you they wouldn't be able to give you a good
| estimate either.
|
| Research is a better comparison. How long will it take
| you to build a fusion reactor? Depends, right?
| bumby wrote:
| There's a lot you've said here that I agree with, but I
| think we use it to arrive at different conclusions.
|
| FWIW, I've worked in software, automotive, and aerospace.
| They are probably more alike than you may realize. Vague
| requirements are quite common. The link above has a
| section specific to software development, so I don't
| think it's fair to say it only applies to physical
| systems. I would characterize it as a systems approach,
| rather than domain-specific. It uses "WBS" or "work
| breakdown structure" to delineate tasks. That's an
| approach that is agnostic to the domain. So if you're
| working on a mechanical system you might have propulsion,
| deployment, and control surfaces. If you are working on a
| software system, it might be user interface, command &
| control, and data acquisition. But the applicability of
| the method is the same.
|
| What I think you highlighted is that SWE is generally
| much less well-managed than other domains. Mechanical
| engineers often get vague requirements but implement much
| more standardized processes in their work to hone in
| those requirements, largely because the costs of jumping
| in and iterating are much higher. By comparison, software
| development is the wild west. Like you said, software is
| virtual, so people are lulled into complacency that they
| don't need a structured process because they can build
| and make tweaks cheaply. But what you point out isn't
| really that software development is inherently different,
| but just that it's not managed well.
|
| I think your research comparison misses its mark.
| Research isn't involved with developing some end-stage
| product for a consumer. The 'product' of research is an
| experiment and every research project I've been involved
| with starts with an estimate of how much that experiment
| will cost and how long it will take. And that follows the
| same basic structure as any other development effort.
| Maybe it's an apt comparison for some yet-to-be-proven
| tech like self-driving cars, but it doesn't explain why
| most basic CRUD applications miss cost and schedule
| estimates. I think the answer is that most software
| development has a culture that isn't as well developed in
| process control.
| bluefirebrand wrote:
| > If 'objective one is to get paid' it comes across as
| primarily a monetary transaction. That's generally not
| how the people I know who are really fulfilled in their
| careers look at it.
|
| Having a fulfilling career is a myth sold to you by
| employers.
|
| Focus on getting paid enough to have a fulfilling life
| instead.
|
| After all, chances are the higher ups at your company
| will fire you at the drop of a hat if they think it will
| secure them a bigger year-end bonus.
| ruszki wrote:
| Except it's not necessarily. As a software developer, you
| have the privilege to not really care about money if you
| don't want to. I didn't have money problem, ever. Without
| even trying. I can fly three times between Europe and
| America, and about 20 more times inside the continent in
| a year, and I can still put about third of my salary to
| saving. And I live in a country now where software
| developers are heavily underpaid: Austria. Most of my
| friends in other fields can't even imagine my life -
| their exact words.
| bluefirebrand wrote:
| > As a software developer, you have the privilege to not
| really care about money if you don't want to.
|
| That sounds nice for you, but your experience is not
| common I don't think. It's certainly not my experience as
| a software developer in Canada, where I struggled for
| years and even now make "just" a comfortable living.
|
| I'm very happy I don't have to worry about rent and
| groceries and I can save quite a bit, but I'm certainly
| not able to "not care about money"
| cartoonfoxes wrote:
| HN has a high concentration of above-average salaries,
| even within the US. It's tough constantly hearing how
| many multiples more my southern equivalent at FAANG is
| earning without it affecting my sense of self worth.
| bumby wrote:
| I think this is one of the major downsides of focusing on
| money as the primary part of a job. It can easily become
| a constant comparison, which has a natural way of making
| you miserable.
| bumby wrote:
| Is it a myth if people have managed to do it? It takes
| some self-awareness and conscious decision-making, but
| it's certainly possible.
|
| IMO, a focus on getting paid can lead you to optimize the
| wrong things in life, making fulfillment less likely than
| more. It has a weird way of changing your value system by
| changing what you focus your attention on.
| Trasmatta wrote:
| How many people in the world (, software engineers or not)
| actually have the privilege of enjoying their jobs after 30
| years?
| Helmut10001 wrote:
| I actually read that he is enjoying his job and has a healthy
| attitude.
| red-iron-pine wrote:
| Aye. Sounds like there are no illusions and a "lets get it
| done so we get out at 5pm sharp" attitude.
|
| The "I love coding and need to stay to 8pm every day
| because we're going to change the world!" is insufferable.
| Hit whatchu gotta hit, don't play the games, and push the
| release out the door. Then get out there and live life.
| codeTired wrote:
| I love programming but can't drink the koolaid.
|
| I haven't found a company yet that meets my energy. All I get
| is people "excited" to be working for their company because
| they are "changing" the world. It's marketing vomit.
|
| To be honest I would prefer to have few million dollars in
| investments and not to work for anyone at all. No arbitrary
| deadlines, no corporate ladder, no politics.
|
| I just want to write some code, build some servers and play
| with things. Maybe make something that benefits people in
| general.
| wiz21c wrote:
| > It's marketing vomit.
|
| An understatement. Do these people actually believe in it ?
| Or are they just faking it because one has to adhere to
| company's value ?
| evantbyrne wrote:
| Most people are faking it. Being able to spend your time
| on something that both significantly improves humanity
| and pays the bills is a rare opportunity.
| staunton wrote:
| I don't think that's really true (though the claim might
| be too general to even evaluate on its merits). The same
| way that I don't believe most religious leaders are
| secretly atheists.
| baz00 wrote:
| I dunno I'm an atheist and I've thought about starting my
| own cult occasionally :)
| lambdasquirrel wrote:
| I've always wondered what substances people are using,
| the more that they have to touch that stuff. When I was
| more naive and inexperienced, I was blind to this, and I
| also judged it.
|
| Nowadays, as long as the marketers are taking care of it,
| and they aren't ruining their health, I don't care what
| they're taking as long as it's not meth.
| manicennui wrote:
| I always wonder this. I think many people actually
| believe the bullshit because they aren't intellectually
| curious and have spent no time exploring how other
| organizations might work. This becomes a problem for
| software engineering because they have nothing to draw on
| other than their past work. If they haven't worked
| anywhere other than your current employer, and your
| currently employer is a dumpster fire, they are going to
| continue to repeat bad patterns.
| jameshart wrote:
| In a company whose business is software-mediated (which is
| basically all businesses these days), there are a bunch of
| people who are excited to be part of the journey... and a
| bunch of tech people who have the power to actually do
| things because their hands are on the keyboard and they can
| make the business change.
|
| I know which group I would rather be part of.
|
| Given that being paid to do things is going to involve
| working for some sort of business, I'd rather be in
| software development for such a business than in marketing
| or sales or HR or operational support...
| bityard wrote:
| > To be honest I would prefer to have few million dollars
| in investments and not to work for anyone at all.
|
| This is possible, especially on a tech salary. Have you
| heard of the FIRE movement?
| codeTired wrote:
| Of course I have. I do make good money but not $500k.
|
| I'm hoping to increase my net worth by few millions in
| the next 10 years. Getting close to my first one.
|
| I might grind and go for a big tech job, but it needs to
| be remote.
|
| I then plan on either working an extremely laid back job
| where I put in 10 hours a week and collect a salary
| without giving much fucks or doing something exciting
| that might not pay so much.
|
| Maybe I will find something along the way that excites
| me.
| bluGill wrote:
| Ever hear the term "mid life crisis"? It exists because
| people around 40-50 - that is 20-30 years into their job they
| realize they have been doing the same thing and it is getting
| boring.
|
| While it isn't too late to consider a career change, I'm not
| sure that is a good idea. For some it is, but many stay -
| particularly in tech - because they can make a lot of money
| and thus afford some hobbies that are not boring. Often this
| is overall your best course in life: find a hobby you enjoy
| and keep doing your job.
|
| Obviously everyone needs to make their own decisions.
| mihaitodor wrote:
| Spot on! After 16 years, I'm looking to get back to academia
| and do a PhD. I felt like I don't enjoy what I'm doing for
| far too long, even though I changed jobs about 8 times.
| Tangurena2 wrote:
| > _It's not healthy to have this much disdain and displeasure
| around your work._
|
| The disdain and displeasure is a result of experience. Of
| knowing what needs to be done and not being allowed to do it.
|
| > _The right way, the wrong way and the Army way_
|
| Usually, the problem is the sort of people who get promoted
| into mismanagement. They were good at "people skills" (and
| all too often - their only skill is sucking up to their boss)
| and bad at programming. This is a systemic problem that I
| have not seen any sort of possible way to fix in all the
| decades I've been working (or visiting dad's office when a
| youngster). If you could find a way to ensure that only
| skilled managers get promoted (and incompetent ones fired),
| you will fix Capitalism. No more Enrons. No more Innitech.
| notabee wrote:
| It's a self-perpetuating process though, since the
| productive, skilled workers are by definition spending the
| majority of their time learning and doing productive
| things, while the remainder have the majority of their time
| freed up to play political games and elect more of their
| own political kind into leadership roles. That tends to
| increase the workload of the productive people, further
| pushing them away from the nexus of decision-making as
| they're too busy keeping things running. Eventually a
| crisis occurs in the top-heavy organization (or society,
| even). The doers burn out or leave, only demanders remain,
| and everything goes to shit.
|
| Perhaps worker-owned companies could help with this, but
| I'm sure that the time investment imbalance dynamic would
| still be an issue to contend with.
| hello_moto wrote:
| WAT? Seriously? Career change?
|
| Your parent post is on-point. You can be passionate about
| your job and still do the things that he said he does.
|
| You're gunning for absolutism while parent's post is realist.
|
| I love my jobs (yes, all of my employers) but there are few
| meetings that IDGAF but have to be there because of many
| reasons. I muted myself and do something else.
|
| I used to be an idealist but I slowly changed my approach
| because I realized at the end of the day, I'm dealing with
| human beings day-to-day.
| nsxwolf wrote:
| It absolutely might be too late for a career change. If
| you're paid well, and have come to rely on your income,
| staying put is likely your only realistic option.
| dontlaugh wrote:
| It's a job, trading labour for money. Enthusiasm isn't a
| requirement, it's not an acting job.
| gosub100 wrote:
| > I feel bad for the commenter
|
| yeah the post where you don't even directly address him, its
| just teeming with compassion.
| agentultra wrote:
| Big boomer energy here: it's called _work_ for a reason.
|
| You don't have to enjoy every minute on the job. It's not
| likely that you're going to be working on passion projects
| every day. You're not even going to be intellectually
| stimulated by the vast majority of tasks you will be given.
| You need to get used to the fact that almost every job as a
| programmer is probably going to be working on a system that
| retains eyeballs on screens, counts something, or shuffles
| around forms.
|
| When you do this for twenty or more years it gets pretty
| boring. Where are all of the data structures, type systems,
| formalizations, optimizations, etc? Taken. There are a few
| people who get lucky enough to have jobs where they can work
| on things that interest them, where they get to work on hard
| problems that get them out of bed and plague them while
| they're in the shower. But they don't leave those jobs and
| there aren't exactly a ton of new ones being created either.
| Unless you're lucky enough to be in the right place at the
| right time to get into one of these jobs, you're more likely
| to be sitting in meetings and filing JIRA tickets.
|
| Cherish the times when you _do_ get to work on a project that
| piques your interest. It can happen. But it 's rare for it to
| last for most people. You have to sustain your interest and
| curiosity in other ways. And it's totally fine if it's
| anything to do with not-programming.
|
| Meanwhile, on the job? Do your best, show up, be nice and
| professional. You'll do fine. You're here to clock in your
| time for money so that you can do other things that you
| actually like: reading books, spending time with family, doom
| scrolling, etc.
| lambdasquirrel wrote:
| When I was in college I had a professor who joked that her
| standards had gone down over the years. Nowadays, her only
| criteria are: "no criminal record."
|
| Maybe it's just a joke and we don't need to get that
| cynical, but I think that in the end, enjoyment of the work
| comes from: whether you can find some creative process in
| it, and whether you like your coworkers. I think this is
| the optimistic way of looking at "work is called work for a
| reason."
|
| To that end, even plain-old programming beats a whole lot
| of other fields. But to think that we should be drinking
| the kool-aid and all is definitely not going to stick for
| the vast majority of us by the second or third decade. I
| certainly enjoy my job, even though it's just "work."
|
| My professional life and mental health definitely improved
| when I finally accepted this in full. Whereas at my
| previous job, the entrepreneurs sold everyone on using the
| tools and languages of their choice (and sacrificing for
| compensation in a big way). Noble attempt, perhaps, that
| _may_ have worked in a different time and era of tech, and
| under vastly different macroeconomic circumstances. But
| ultimately, it should not have been surprising, in
| retrospect, that no one would do any of the work-work that
| it would 've taken to make the company work.
| agentultra wrote:
| > I think that in the end, enjoyment of the work comes
| from: whether you can find some creative process in it,
| and whether you like your coworkers
|
| Hard agree. I look for the interesting things about it
| and try to, "find the fun." It's nice when you see
| something you built work well for people, solve problems,
| etc.
|
| When you get to work on a project that aligns with your
| values and goals, it's a blessing! Take it, enjoy it,
| savour it, and write about it. Dive in deep! When it's
| gone, it's gone.
|
| But there's a lot of busy, necessary work in programming
| that isn't going to be like that and it still needs
| doing.
|
| There are a lot of businesses out there that need people
| to do that busy work and will pay well for someone
| capable, competent, and willing to do it. It's not
| glamorous, exciting, satisfying work... it's work. You
| get paid for it.
|
| _Update_ : s/able/willing/
| fumeux_fume wrote:
| Working for any organization comes with its downsides.
| Pretending like they don't exist and gaslighting someone
| who's come to peace with them for long-term job satisfaction
| comes off as pathetic to me.
| austin-cheney wrote:
| I love writing software and building things that solve real
| problems, but it's astonishingly rare to do this as
| employment. Yet, you still need income as children don't eat
| for free. So for the other 90% of us you have to make a
| choice:
|
| * Go to work knowing you are probably not productively
| writing software and just accept that reality for what it is:
| staring out the window while other people listen to the sound
| of their own voice out loud all day long. And, you often have
| to drive through lengthy traffic to relish in this
| experience.
|
| * Write software outside of work at cost to your marriage,
| time with kids, personal finances, and everything else with
| work life balance.
|
| * Go do something else.
| yieldcrv wrote:
| nah, L take. Have a life.
|
| I remember going to hackathons and wanting forced timed
| experience to build anything. I remember going up to the
| companies that wanted you to build on their stuff and being
| surprised at their substandard APIs and how lackadaisical and
| unmotivated those engineering representatives were, I just
| didnt understand. A fortune 500 team just hanging out a
| hackathon with no capability or interest in providing real
| support?
|
| Now I think back and I realize they just had other things to
| care about
|
| The hackathon and job could be fulfilling, their DIY projects
| at home were _more_ fulfilling.
|
| Their entrepreneurial endeavors were _more_ fulfilling.
|
| Sure, they could be totally checked out and burned out too.
|
| But it doesnt matter, set boundaries with your job because
| that _definitely_ doesnt matter.
| jvanderbot wrote:
| Don't mistake zero-fucks with zero-cares. Staying cool while
| keeping your sleeves rolled up working on fixes is an
| absolute life skill. Knowing it's always "Same shit different
| pile" is maturity, not resignation. Working hard because you
| are a valuable engineer doing a good job, despite knowing
| that the world is full of chaos and nothing will matter in 5
| years is called Professionalism.
|
| Get paid, invest, be chill and fun to work with, enjoy your
| family and friends, go fishing or something.
| manicennui wrote:
| I don't think it is reasonable to expect to truly enjoy one's
| job. This seems like a luxury that some people in certain
| fields might enjoy, but most of us tolerate or hate our jobs
| and wouldn't do these activities by choice.
| throw555chip wrote:
| Weird takeaway, I thought the comment was brilliant and spot
| on! 30 years here too!
| timacles wrote:
| I used to think like this, but after getting a wife and kids,
| there's just no way a corporate job can be continually
| rewarding like you describe.
|
| Everything is always mired in unpleasant bullshit and
| emotionally detaching like the above poster suggests is the
| most pragmatic way to handle work.
|
| I've lost all desire of proving myself and working on
| interesting problems, because at the end of the day, I'd just
| rather spend time with my family and do fun personal
| projects. Work is work and it will be never live up to an
| idealized concept that you have in your head.
| maxrecursion wrote:
| Point 9 - Eventually you do become able to disconnect from your
| job. One day the fucks just run out. Embrace that early on and
| save yourself a lot of stress.
|
| This is the most important life lesson anyone can learn, but I
| think it can only be learned by going through a flaming
| dumpster fire that burns all those fucks away.
|
| You can't get that confidence and no fucks given attitude on
| your own, at least not for most people. You have to go through
| the shit and earn it.
| crabbone wrote:
| Just to comment on incompetent people. There are kinds of
| incompetence. It also makes a huge difference where in the
| hierarchy they are. Incompetent boss will not let you save the
| day, but will make you take the blame, for example.
|
| Here's an example of incompetence I deal with every day. The
| head of R&D department either pretends not to understand or is
| genuinely this stupid as to engage in the following process
| over and over:
|
| * We release a program with many defects due to the short
| development and testing cycle, but especially due to poor (or
| missing) planning.
|
| * Customers complain they cannot achieve what they want using
| our program.
|
| * R&D lead bravely rushes to "extinguish the fire" by adding
| new feature to work around the customers' complaint.
|
| * Because the feature was never properly planned it creates
| multiple new issues while coming late to the testing stage.
|
| * We burn past the deadline, and eventually have to release
| still half-baked.
|
| * Customers complain again...
|
| There's no place in this scenario where any of the underlings
| can swoop in and save the day, because saving the day would be
| to tell the R&D head that he needs to go through due process of
| planning his contributions and coordinating with other
| department heads, esp. the QA. But nobody can, because this
| will be judged as insubordination and violators will be fired.
| Over half of the underlings are on work visa, not to mention
| that the company is almost exclusively filling its niche. So,
| nobody wants to speak up out of fear of being fired.
|
| On the other hand, such incompetence only lowers morale,
| leading to most underlings losing interest in the subject
| matter and doing the absolute minimum to hold the job. You'd
| think it's a miracle such a dysfunctional company keeps
| sailing... but, I have this to tell you. This is not the first
| company of this kind I met in my life. All companies of this
| kind that I've met by the time I've met them were over 20 years
| old, profitable, big, fearlessly looking into the future...
| vsareto wrote:
| How sure are you they are incompetent vs. just not giving any
| fucks/disconnected from the job and there to get paid (it's
| objective one after all!)
|
| This seems a little inconsistent to me.
|
| Is it really their fault if the industry says they are
| qualified and gives them a job when they are incompetent?
| baz00 wrote:
| Well the people who don't give any fucks want to make their
| life easier so they do a minimally competent job and are
| usually supremely skilled avoiding pain. The disconnected
| people don't actually do any work at all. The incompetents
| cruise in, full of ego, poop everywhere and expect everyone
| else to clean it up and take responsibility for it. I don't
| mind that job because it's an open ended task. As for it
| being their fault, no it's not really, you're right. But
| management need butts on seats apparently so standards will
| be reduced until they are full.
|
| Also many incompetent people, when faced with enough pain,
| will turn into competent people and eventually stop giving a
| fuck too.
| Tangurena2 wrote:
| I think that one very important issue got left out: _always be
| learning_. The colleagues that ended up having to change
| careers were ones who refused to keep current with technology.
| Or who treated education like a vaccine: "get it" once and
| never again. "Learning how to learn" is probably the most
| important skill one learns in college, yet it is treated as a
| side issue (if at all). So many tech stacks have ended up on
| the "dustheap of history", yet we have to constantly learn new
| ones.
| colonelpopcorn wrote:
| "It's nothing personal, it's just business"
| andai wrote:
| Truly the love of money is the root of all evil...
| jmyeet wrote:
| > Point 4 - incompetent people. They are great.
|
| I used to think this too but it rarely works that way in
| reality. Why? Because, as Roger Sterling put it, "Half the time
| this business comes down to 'I don't like this guy'".
|
| Incompetent people survive because, for whatever reason,
| they're liked that decision makers, who may themselves be
| inccmpetent. Or it may be they're just similar in outlook,
| background or interests. It doesn't matter. Or they may be
| politically savvy enough to take credit for things that work
| and deflect blame when they don't.
|
| I've seen teams spend a half on something, not launch anything,
| make a post about "we learned a lot" and get praised for thier
| "achievements".
|
| > Point 5 - meetings are great if remote.
|
| For many people, myself included, this is still incredibly
| distracting. You can't switch off entirely.
| lencastre wrote:
| Money, Assignment, and Team -- if any of these two are shitty
| then find a new job. But be honest with yourself.
| notac23 wrote:
| Learning point 9 early will save you a lot of pain.
|
| I'd add this: Care about your job, do your best, learn, grow.
| It'll serve your career and it'll serve your
| happiness/satisfaction.
|
| HOWEVER, accept that things will go wrong/dumb decisions will
| be made, and it's not all up to you to fix. If other people
| make dumb moves, you don't have to die on the hill. Let others
| fail, it's good for them too. I promise you that nobody will
| actually care after it's over. It's not worth the mental agony.
| BeetleB wrote:
| > The only soft skill is politics.
|
| This statement is void of content - virtually a tautology.
|
| All soft skills are politics. Politics is large in scope. You
| do a favor for your friend? That is politics of the "good"
| kind.
| StillBored wrote:
| For a software engineer, these are great points to follow if
| the goal is to be the incompetent person on the team in a few
| years...
|
| Personally, while I find myself frequently in too many meetings
| or spending way too much time with email, or $DEITY, git
| rebasing to satisfy some power-hungry gatekeeper it is the
| little side projects that save my sanity. While many are the
| equivalent of throwing paint on a canvas, it is cathartic. So
| maybe the one good thing to come out of the google mgmt style
| that everyone seems to have copied (not the side project bit,
| all the other garbage) is the 20% time.
| loeg wrote:
| Jaded and cynical as hell.
| nikolayasdf123 wrote:
| so true.
| ptero wrote:
| While many points are true (but IMO not all) I would not see all
| of them in a negative light. Especially for a new grad just
| starting in the field.
|
| For example, yes, you will likely work with existing codebases,
| but in most other professions you will work within established
| constraints, not all of which are fun, etc.
|
| On the flip side, a good knowledge of software engineering offers
| excellent money and opens a lot of doors. Want to live and work
| in Europe for a few years? Take 3 months (unpaid) off to surf and
| recharge? Negotiate remote options? A good software engineer is
| likely to manage those with some negotiation and planning. Not
| many other professions would allow that today. My 2c.
| mypastself wrote:
| The bullet points in the article are reasonable enough, but
| almost every explanation is questionable. I'll just address one.
|
| Soft skills are indeed very important, and sometimes more so than
| technical skills. However:
|
| > Technical skills are the ones you can learn easily. With
| different projects, you can understand a particular programming
| language. You can learn its syntax, pros and cons. It's just a
| matter of practice.
|
| Technical skills are not just about programming language syntax.
| I wonder how long the author's been in the industry (apparently
| "a lot of years") or how narrow his role is, that he's never had
| to learn completely new concepts or paradigms.
|
| And even the soft skills section is bizarre. What can I learn
| about utilizing my soft skills from the author's list of all the
| times they thought a colleague was unhelpful or "toxic"?
|
| Weird article.
| demondemidi wrote:
| I'd say OP has 5-7 years. Because if you have both soft and
| technical skills together you stop writing code after about
| your first decade and start solving much larger problems.
| davewritescode wrote:
| This is bad advice in many organizations. The best architects
| I've ever worked with were excellent coders and kept up to
| date with everything even if only 10% of their role involved
| writing actual code.
|
| It's very hard to be a technical leader without credibility.
| atq2119 wrote:
| Indeed, I see a big difference between developers in my team
| based on their general reasoning and discrete math skills. How
| capable are they of abstractly interpreting code in their head?
| Are they used to thinking about how to prove something is
| correct? Are they used to thinking in terms of graphs? That
| sort of thing. Those are technical skills that seem pretty
| difficult to learn.
| charles_f wrote:
| > I wonder how long the author's been in the industry
| (apparently "a lot of years")
|
| 8y, most likely including internship. His resume is on the
| blog. I wondered as well and checked.
| nfRfqX5n wrote:
| This stuff could roughly apply to any job
| kossTKR wrote:
| Most problems today stem from scale? A big org of with 100% non
| technical people and 100% technical people where the sweet spot
| was the small game studio from 25 years ago, nerds, but social,
| tightly knit, experts but generalists because of size, close to
| each other, and pretty small.
| 1270018080 wrote:
| Reads like a chatgpt article. Nothing new or insightful or hard
| to swallow.
| FranzFerdiNaN wrote:
| > You have to put in extra work while you are in college. Code
| more projects besides homework and seminars. Do some
| volunteering. Learn about business domains to prepare for the job
| that awaits you.
|
| lol yeah, or you do not do this and just get paid to learn all
| this shit on the job.
| mberning wrote:
| 3) People and businesses usually won't value your "clean code".
|
| 4) You will often work with incompetent people. Especially in
| larger organizations.
|
| Pretty well agree with everything else.
| lnsru wrote:
| Sounds very nice. Nobody talks, that highly paid jobs attract all
| levels of psychopaths. And nobody teaches to work with or under
| them. Then you go into psychogames asking if I am insane or
| something wrong with this workplace. If you're lucky - you leave
| early and healthy. If not - end in some fancy mental health
| clinic.
|
| Already mentioned layoffs. My older colleagues went through these
| too. But really only when the company was going bankrupt. We have
| now lifestyle layoff rounds to prepare companies for future
| challenges. Some dude in completely healthy and profitable
| company decides to throw away 5% or 7%. Job security is gone. At
| the end you're a row in payroll's excel.
| sergioisidoro wrote:
| "Nobody gives a f** about your clean code"
|
| Absolutely false. And you'll know this as soon as you need to
| change or maintain your own code.
|
| Even if you're a purely cynical person who does not care about
| your team members, or the future developers (and you're just
| optimising for business outcomes) you have the incentive to save
| yourself a lot of pain, as well as embarrassment when customers
| ask you for something and you need to say no.
|
| I would, at minimum, rephrase that point to "Do clean code for
| you (and for your colleagues), not for some abstract virtue of
| writing clean code"
| politelemon wrote:
| Looking at the paragraph that follows that headline, they are
| already making similar points.
| pnut wrote:
| A less charitable interpretation is that "Nobody gives a f*
| about your clean code, because if you're dealing with code,
| you're a nobody in the business"
| RcouF1uZ4gsC wrote:
| These kind of essays are needlessly negative.
|
| In terms of being relatively accessible, well paid, safe,
| interesting work software engineering is probably one of the best
| jobs ever in the history of humanity.
|
| Yes there are downsides, but IMO they are relatively minor and
| pretty similar to what people in any other field experience -
| incompetence from coworkers, office politics, too much time
| talking and not doing, and the concern for the bottom line of
| some ideal of perfection or craftsmanship. In addition, for most
| jobs that require college, what you learn in college is only the
| foundation and you will need to learn a lot on the job (see for
| example residency for doctors, flight hours for pilots, clerking
| for lawyers, etc)
|
| In exchange, you get a relatively well paid job that only
| requires a 4 year degree (if that) to land an entry level job.
| There is a vast opportunity for increase in pay either through
| experience or starting your own company. In addition, if you want
| to start your own company, it is one of the easiest fields with
| much smaller regulatory and capital requirements compared to
| almost anything else.
|
| It is not just well-paid work, it is interesting work. Lots of
| people, including me, find software engineering fun and
| fulfilling. There is just something amazing about creating
| something cool. Many of us like this so much, we have non-work
| side programming projects of our own.
|
| Software engineering also offers some of the best work-life
| balance potential of almost any high paying field.
|
| And again, compared to other high paying professions, it is much
| easier to get into. Although people complain about interviews,
| they are less stressful than trying to get into medical school or
| law school and there are a lot more entry level programming jobs
| than medical school and law school headcount. It is also much
| more accessible than anything in entertainment or media.
|
| So in summary, like everything else in life, it is not perfect.
| However, currently, it is one of the best, most accessible
| careers, possibly in the history of human civilization.
| djtango wrote:
| In TFA, author uses a swimming analogy and it's alright but for
| me I find martial arts is the most relatable analogy and so many
| of Bruce Lee's thoughts are applicable...
|
| A lot of what you will learn in a degree is like doing your
| katas. They're fun to learn but many (if any) of the moves are
| too situational and abstract that you'll rarely get the chance to
| apply them. And when you do, you may forget about them in the
| moment under pressure.
|
| But learning those techniques in a safe environment you'll have a
| chance to develop some finesse and also have good technical
| foundations. But there's no replacement for actually getting
| field experience by sparring/fighting.
|
| A seasoned brawler/street fighter will seem uncouth and may have
| some unorthodox habits but they will be more successful in the
| day to day than most theoreticians who aren't out there applying
| what they're learning.
|
| Some Bruce Lee quotes I like wrt software engineering...
|
| _Adapt what is useful, reject what is useless, and add what is
| specifically your own._
|
| _If you spend too much time thinking about a thing, you'll never
| get it done._
|
| _Before I learned the art, a punch was just a punch, and a kick,
| just a kick. After I learned the art, a punch was no longer a
| punch, a kick, no longer a kick. Now that I understand the art, a
| punch is just a punch and a kick is just a kick_
| throw555chip wrote:
| > A seasoned brawler/street fighter will seem uncouth and may
| have some unorthodox habits but they will be more successful in
| the day to day than most theoreticians who aren't out there
| applying what they're learning.
|
| That reminds me of my favorite Bing Bang Theory scene, on the
| way to Comic Con their car breaks down. Leonard asks if anyone
| knows anything about automobile engines. Everyone (theoretical
| physicists or astrophysicists) raised their hands
| enthusiastically. Then Leonard asks, OK, does anyone know how
| to repair an automobile engine? Everyone lowers their hands.
| SlapnutsGT wrote:
| 9 - I've been doing this so long and this gets harder and harder.
| I'm at the point I'm so severely burned out I'm planning early
| retirement to get out of this industry all together. For me what
| makes it even more worse is I didn't get into this field until I
| was in my 30s. Beforehand I drove a forklift in a warehouse, I
| was in the military, then an electrician, and finally a
| electronics repair tech afterwards. Those fields the disconnect
| was passive, didn't even have to think about it. Software you
| have to jump through mental hoops to remove yourself and that's
| just as exhausting as the job itself. I dream of a job working at
| a garden center or maybe driving a forklift again. This field
| sucks.
| lr4444lr wrote:
| Pretty good piece. All new devs should be lucky if they find an
| org that is exempt from even 1 or 2 of these problems.
| rubyfan wrote:
| I think a lot of this is good advice even for people outside of
| software engineering.
| alkonaut wrote:
| > The user doesn't know how the codebase looks
|
| Technically true. But the user knows when code is in a poor
| state. A poor C codebase in a security critical area users will
| find out about. It will crash, need critically patching all the
| time etc.
|
| If a game engine has a messy code base (Say, they have two
| slightly different renderering subsystems which makes things
| clumsy) then people will notice because the games will be late,
| buggy, cancelled whatever.
|
| For most users though it's that the software is slow, costly,
| buggy, doesn't get new features quickly and so on. And you can't
| really tell the reason why. But users DO notice it. Managers
| certainly notice it. Any manager should recognize a situation
| where you spend 80% of your time on bugs/regressions, while new
| features get less time, and take much longer than aticipated to
| implement. And any manager should instantly recognize that this
| is invariably due to a poor-looking codebase. Not poor
| communication, not (other than indirectly) because of bad
| developers, not poor tools, not anything else. Just messy code.
| braza wrote:
| > You will rarely get greenfield projects
|
| If only I had known that one earlier. I was fortunate enough to
| work only on greenfield projects for my first fifteen years as a
| software engineer. However, at some point, I was brought into a
| brownfield project [1] for maintenance, support, and bug fixes.
|
| The difficult part was not related to things like clean code,
| architecture, and so on, but to the lack of consistent thought
| processes around the choices made, as well as the fact that there
| is a lot of tacit knowledge in people's heads that aren't
| documented, and how arbitrary convoluted things can be,
| especially if foliks wants to ensure their own employability
| through manufactured complexity.
|
| It took me at least three years to realize that new technology is
| the exception rather than the rule.
|
| [1] - Brownfield project it's something that has something green
| still but starts to be muddy and swampy.
| Joel_Mckay wrote:
| 1. Most academic institutions were never intended to subsidize
| corporate training costs. While this line sometimes gets blurred
| these days, one must assume you are learning basic skills 80k
| other people already have.
|
| 2. The primary HR issues I've seen is a lack of humility,
| inexperience, and people entering the field for the wrong
| reasons. Financial motivations are fine and all... but giving a
| toss about what you do is important in the long term. There is
| zero correlation between degree level and productivity... Indeed,
| some kids get by on social media with an army of Googling friends
| to try and game through challenges (think of a Borg-cube that
| assimilated a planet of smug morons.)
|
| 3. Some people are cultists, and firmly believe success is
| bestowed on the truly deserving. In some ways they are partially
| right for a cog-in-a-machine proprietary process position.
| However, the range of skills needed grow exponentially as the
| organization shrinks, and rapidly deprecates people not willing
| to show any initiative.
|
| 4. Your work is likely naive garbage at first, and while
| management doesn't know any better... your peers do. Expect to be
| hazed until one can contribute coherent work. Yes, you will be
| working on projects that match your skill-set, and if you don't
| clue in your career will be a short one.
|
| 5. Assume you are the dumbest person in the room, and be
| pleasantly surprised when you are wrong. Some folks have
| literally met 80k people just like you, and whatever cleverness
| you think is original... is often just tedium in another
| perspective.
|
| 6. Your loyalty will not be rewarded. The industry will not
| suddenly develop integrity, but it is rather a personal boundary
| you choose after seeing peers exploited.
|
| Good luck. =)
| kiviuq wrote:
| no one cares about providing value to users. We could create
| value without making profits. People care about profits nothing
| else.
|
| So, no I think your sole purpose as an employee is to make other
| people rich, as in any other profession.
|
| But there are worse fates in life than writing code for money.
| ChrisMarshallNY wrote:
| Well, I liked they used MonkeyUser comics. I feel those guys "get
| it." Sort of like a more tech-relevant Dilbert (without the
| racist screeds).
|
| I was a software engineer for a long time, and a "first line"
| manager, for a long time.
|
| Most of the points are correct, but some did not apply, in my
| company.
|
| For one thing, I worked for a Japanese corporation, and clean
| code was a _really_ big deal to them. I had a project canceled,
| once; partly because the code wasn 't up to snuff.
|
| If you work for a Japanese company, get used to meetings. They
| _absolutely love_ meetings. Especially in-person meetings (rack
| up those frequent flyer miles!).
|
| That said, I really enjoyed the job. It taught me to write
| Quality code (which means absolutely nothing, for most tech
| companies), and they treated me and my team with respect. That's
| not something that you'll get, in most modern tech companies, and
| it meant _a lot_ to us all.
| esafak wrote:
| Why do they love meetings? I assume you mean managers love it?
| ChrisMarshallNY wrote:
| It's an artifact of their consensus-based decision-making
| process (they have _lots_ of process).
|
| Meetings are a crucial part of obtaining and expressing
| consensus.
|
| It can get pretty crazy, but they get things done.
|
| Whenever we look at the way that another culture does stuff
| (not just other nations -other companies, as well), we tend
| to look at it through the lens of "That's not something _I_
| could do! ". We need to remember that their culture is
| acclimated to doing things the way they do it; for better or
| for worse. They actually can have a difficult time, adjusting
| to the way we do things in the US.
|
| We had a liaison that wanted to help things be more "agile,"
| so our infrastructure/process guy suggested daily morning
| standups (you know, informal, 15-minute meetings in the
| morning).
|
| He turned that into once-a-week 1-hour sit-down meetings
| before lunch on Fridays, with a rigorous format.
| esafak wrote:
| Consensus-seeking reduces variance. This is the approach to
| take when failure is expensive. Blindly applying this
| approach leads to design by committee and wasted
| productivity.
| ChrisMarshallNY wrote:
| Like I said, it's a "cultural" thing.
|
| It works for them, but there are many drawbacks.
|
| I will say that the Quality of the stuff this company
| made was staggering. Not a huge money-maker, though.
| Their process had levels of overhead that would have most
| folks on this site, huddled under their standing desks,
| whimpering.
| throwaway_08932 wrote:
| > Sometimes you don't know the whole story. I have seen some
| cases where a person just can't do their job properly. They are
| burdened with tons of tasks and doing work for 2 people.
|
| Never mind people who are just starting out -- I think many
| people on HN could really benefit from this perspective.
| jameshart wrote:
| So his 'downsides' amount to:
|
| 1) you'll learn more in the first six months than you learned in
| four years of college
|
| 2) you'll be trusted to contribute to large complex important
| systems
|
| 3) you'll be measured on your results
|
| 4) real ability will help you stand out and succeed
|
| 5) you'll get to collaborate with loads of different people
|
| 6) your work will have direct business impact and visibility to
| senior management
|
| 7) you'll spend most of your time solving hard puzzles
|
| 8) you'll have tons of freedom to define your own path and role
| and find how to contribute
|
| 9) your work will be so compelling your mind will keep working on
| it after hours
|
| 10) the role balances technical and people skills and rewards
| those who can combine those aspects.
|
| > Conclusion
|
| > Software development is not a dream job.
|
| Speak for yourself. I'm having a blast.
| nisa wrote:
| I'm with you but it depends on the company - I was responsible
| to keep it running for the customers and my boss thought it's
| better to let me churn out useless work that he can bill
| instead of fixing the issues or simplify the process (at least
| internally). I even proposed that he can just bill the same or
| more hours for the customers for me but I need to automate that
| shit or I'll go insane. Didn't happen. As soon as I realized
| that I quit but I burned out pretty badly trying to make it
| work because I liked the team and the product. Be careful and
| watch out where you spend your energy and time.
| dvcolgan wrote:
| I appreciate this positive spin on the list. There is usually a
| silver lining.
| psiops wrote:
| Indeed, reading these hard-to-swallow truths actually restored
| some excitement about being a dev for me!
| nunez wrote:
| Love this reframing.
| ozim wrote:
| I think software development "is not a dream job" as people
| outside think it is.
|
| Most of the time people think you get paid for sitting behind
| the screen. Which is also true and might be hard for some types
| of people on its own.
|
| But a lot of people don't want to be measured on results, don't
| want to deal with learning new stuff on the job, having
| responsibility for something complex that might break at any
| time quite often for reasons totally not in their control.
|
| I like my software dev job and I also would not switch but I
| can see how it is not a dream job.
| Izkata wrote:
| > as people outside think it is.
|
| > don't want to deal with learning new stuff on the job
|
| I think this might be the big one. A few years ago I got
| small window into someone going from no programming
| experience to getting a job (completely self-directed, not
| through school or a bootcamp) and he thought he had to learn
| everything before getting the job. I had to reassure him that
| no, that's really not how it works in tech - even if you
| could learn all of ___ right now, there's stuff continually
| being added so you'll have to keep learning anyway. Basically
| that typically you'd get the basics down then learn new stuff
| as you needed it.
|
| His previous experience mostly came from a mix of skilled and
| unskilled laborer jobs, where even the skilled laborer ones
| you could learn everything in like 6 months and from there
| onwards it's just refining skill (as he described it, at
| least).
| RevMuun wrote:
| > But a lot of people don't want to be measured on results,
| don't want to deal with learning new stuff on the job, having
| responsibility for something complex that might break at any
| time quite often for reasons totally not in their control.
|
| See the blog's paragraph on incompetent colleagues. :D :D
| hooverd wrote:
| What is the measure for results though? Is your manager
| competent? Is your team leadership's golden boy or the black
| sheep?
| emberfiend wrote:
| Well said. I think misanthropy and pessimism are endemic with
| people who spend 14 hours a day talking to computers and don't
| have healthy social lives or many reasons to touch grass.
| FrustratedMonky wrote:
| Might be an age thing. This is a positive spin, and I agree.
|
| But the stress does eat away at health. It can be fun, but it
| is not 'comfortable'.
|
| Maybe it is different if you are writing some mission critical
| code. It can be fun when you are dabbling with web sites, but
| not so fun if a bug will cause someone to die. So stress
| levels, and having a blast levels, can very a lot.
|
| And thus the stress levels over time, can cause health
| problems.
| jameshart wrote:
| An 'age thing'?
|
| Curious how old you think I would have to be to have this
| noncynical perspective.
| FrustratedMonky wrote:
| Like, young enough to still be enjoying things. Sure, I
| felt the same way for first decade. This is all fun.
|
| But later. Not old enough yet to have done 24x7 support for
| a few decades, sleepless nights, 80 hour weeks, working on
| Christmas Morning, to be ground down by angry and demanding
| users. ( no fault of their own because of their own
| turnover. ).
|
| Lack of sleep and stress takes a toll on health. So 'age'
| becomes a factor, because the body gets ground down. Seems
| like the 'optimistic' takes remind me of just starting out.
|
| But, it is probably more of which industry you are in.
| Results vary.
| fragmede wrote:
| eg video games sound like such fun to work on, but every
| report I've heard of from people who actually work in
| that industry make me run away screaming that I've never
| had a programming job in that sector.
| jameshart wrote:
| Flattered that I apparently come across as still in the
| full flush of youthful naivete.
|
| I'm 25 years in to my software development career and
| still finding joy.
| sanderjd wrote:
| Really good reframing and perspective. I think all this
| absolutely _can_ be spot on. I have personally experienced this
| kind of work a few times in my career, and yeah, I agree that
| when I 'm in one of these environments, it's almost certainly a
| better job than anything else anyone else I know is doing.
|
| But I also think the ability to flip the script into this
| positive experience really does vary between organizations and
| even within organizations. And it's basically impossible to
| evaluate it accurately before taking the job and doing the
| first three to six months of work there. And then if you do
| conclude it's not a conducive environment to do great work in,
| it's easy to feel stuck, or to very reasonably feel like you
| might just go through the exact same thing at the next
| organization after putting a bunch of energy into getting
| unstuck.
|
| I don't really have advice here I guess... I think there's a
| lot of luck involved.
|
| I guess maybe my advice would be that I think this is one of
| the good reasons to start out at a "big tech" company if you
| can. They have all these difference that exist across
| companies, but they have them across teams or divisions within
| a single company, and it's both a bit easier to figure out what
| the good teams are, and a bit easier to switch teams than
| companies.
| davewritescode wrote:
| You're having a blast because you have a great attitude towards
| your work and feel empowered. This isn't always true for
| everyone, particularly if you're in a situation where the
| organization around you isn't healthy.
|
| I love software engineering too but being a "key contributor"
| golden handcuffed to an organization that's "optimizing costs"
| has made me appreciate why some people might not enjoy this
| line of work.
| jameshart wrote:
| The thing about 'jobs' is they pretty much all involve
| working for companies.
|
| So 'dream jobs' and 'nightmare jobs' alike are going to share
| all the downsides of that: clueless management, misaligned
| incentives, layoffs, etc.
|
| But my point is, if you're going to have to work for a
| company anyway, software engineering isn't a bad profession
| to choose.
|
| Additionally, if you decide you would rather work for
| yourself than put up with corporate life there are few jobs
| that pivot as easily into starting your own business or
| becoming a consultant.
| davewritescode wrote:
| You're just furthering my point that your good attitude is
| a major component of your success. I agree with you 100%
| and I'm always grateful I get to work in this career, bad
| parts and all.
|
| For the record, you sound like exactly the kind of person I
| like working on my teams.
| tangjurine wrote:
| > your work will be so compelling your mind will keep working
| on it after hours
|
| Do you think for most people, fixing little bugs is very
| compelling, or do you think it could be that people are
| stressed and don't want to get fired.
| jampekka wrote:
| I was lucky to figure this out before it was too late. I was
| studying for CS masters and worked as a software developer for
| ten or so years from quite a young age and started noticing I
| hate most of it, and it was just getting worse.
|
| I love programming, but vast majority of software development
| isn't programming even if you work as a "programmer". It's a
| constant bureaucatic fight with piles of horrible codebases and
| technologies and bad ideas (that aren't even yours).
|
| I switched to academia and now I actually get paid to program.
| Not ridiculously like most white collars, but still unreasonably.
| And I don't have to turn into a badly fitting mindless cog for
| the prime hours of my life.
| greenthrow wrote:
| This is a pretty good article and I suspect a lot of it applies
| to almost any job. Replace software engineering with accounting
| or electrical engineering or whatever and it's probably all still
| true. Working with other people can be difficult, soft skills and
| kindness are what make it less difficult. Find places where the
| culture is a good fit for you and where the interviews focus
| heavily on behavior.
|
| Also, work on yourself. There's a lot of toxic attitude in this
| post and even more so in these comments. Stones and glas houses
| come to mind.
|
| You don't have to be apathetic in response to the realization
| that politics is a major thing at higher levels in bigger
| organizations or that estimates will almost always be wrong.
| That's like not enjoying sunny days because eventually there will
| be bad weather. Very silly.
| analog31 wrote:
| The thing that struck me was that the points would ring true for
| virtually any profession. Yet most young people migrate the
| transition into the working world OK, and even thrive.
|
| The one unique thing about coding might be the intractable
| problem of estimation.
| lloeki wrote:
| > As in every job, you will sometimes have incompetent people in
| your environment. Working with them is very frustrating. They
| waste so much time and create a toxic environment. On top of
| that, they are extremely unproductive.
|
| That is not even the worst case. There are incompetent people out
| there that _look like they are productive_.
|
| An example: once we had to implement a bridge to an API to some
| piece of software from some third party vendor that one of our
| customers used. This started with authentication. Of course they
| didn't use OAuth or anything like it but their homegrown
| bastardised version: you authenticate with a username + password
| - nope, not a refresh token - and it hands you a temporary token
| that you then use to hit the API until it expires.
|
| Of course it didn't hand you expiration time so you'd have to do
| requests until they failed, at which point you did the login
| dance to get a new temporary token.
|
| Of course it didn't fail with a 403 or any other status code or
| in-band information you could use: everything failed with a 500
| and an empty body. But that's not even the worst part.
|
| Of course there was no HTTPS, so everything went in clear over
| the interwebs. Not to fret, they thought of that: they
| implemented encryption. Oh, before you ask no they did not use a
| Authentication header or anything remotely like it, for the login
| phase they had us pass username+password on a GET request query
| string, with values encrypted.
|
| Of course they did not use anything cryptographically reasonable
| that you could find off the shelf, instead choosing to shoot
| themselves in the foot with using the OpenSSL API to come up with
| their own thing. So they picked the worst possible thing ever,
| ECB - If you have no idea how bad ECB is, click the following
| link and let it sink for a moment that you're looking at the
| ciphertext.
|
| https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
|
| Of course they provided documentation with three code examples
| (C#, Java, PHP) so as to implement it. Of course each one of
| these four had gaps covered by the others, yet the overlaps had
| none of these four things agreeing.
|
| Of course the code for the statically typed languages did not
| even pass the compiler.
|
| Of course the code examples were ostensibly copy pasted from
| StackOverflow, and then further butchered (with localised names).
|
| Of course the actual server implementation was a fifth thing that
| disagreed with the four above. So the easiest way was to "simply"
| MITM their official Flash client and brute-force-reverse-engineer
| the payloads, tuning OpenSSL arguments until your code produced
| the same output as what you intercepted. In a twist of irony,
| this being ECB helped.
|
| And no they did not use anything like public+private keys, DH, or
| even a PSK, however fancily implemented. See, values were
| encrypted for every payload, but how do you make the API server
| understand your first request ever: the login? Of course you
| would not send the username and password in the clear over the
| web! So it has to be encrypted! So you encrypt it and stuff it as
| a value in the query string! But now how does the server which
| has no idea what the key is can decrypt it? Easy! Base64 the key
| and pass it as a second query parameter! Now auth is encrypted
| and the server can decrypt it! To hell with "PS" in "PSK", that's
| for losers!
|
| Of course, somewhere, someone got accolades for having
| implemented that API in record time complete with full
| documentation and examples, ready for folks like us to peruse.
|
| Of course we had to vigorously defend ourselves for being
| comparatively unproductive in front of two CEOs (including ours),
| a CTO, a contractor, and an employee that implementing a client
| to this API is taking us more than an afternoon, and that,
| glossing over the details about the fitness of ECB, it was a
| stupendously pointless loss of everyone's time when the API
| vendor required us to pass the key in cleartext alongside the
| encrypted payload, a fact that probably still eludes all of them
| to this day.
| crabbone wrote:
| I don't think the learning how to swim analogy is good. Where I
| live it's mandatory for children aged 5 and above to take
| swimming lessons and to test out at some point. So, there's a lot
| of involvement with this subject.
|
| Anyways. Theoretical part _helps_. Doesn 't guarantee that you
| learn how to swim, but is a necessary component for you to learn
| well. College CS education is just outright harmful. Not only
| does it not give you practical knowledge, a lot of what is being
| taught is outright wrong. If we stretch the allegory of swimming
| lessons, it would be like if in these lessons, while only
| teaching the theory, the instructor told you that breathing
| underwater is possible, if you try hard enough, or that diving
| and landing flat on your belly is the way to dive.
|
| Another aspect that I find really upsetting about college CS
| education is that it focuses on inconsequential, transient
| issues, at the same time completely ignoring important ones, and,
| at the same time, not investing any effort into trying to
| systematize knowledge. There's very little effort (or non
| whatsoever) put into building advanced concepts from first
| principles. Often times links necessary to connect several
| concepts are missing and the students aren't even told that these
| concepts are somehow related, or even if they are, then there's
| "magic" in derivation which is never explained. A typical example
| would be how in automata theory the course usually ends with
| building some very simple programs using Turing machine, and the
| closest next link in understanding programming languages is
| learning some modern elaborate programming language like C or
| Python.
|
| College CS education is way overdue for a fundamental revision,
| and I wish CS had its own Bourbaki...
| vegetablepotpie wrote:
| Great list. Ten years in, I have to say I completely disagree
| with #6 though. My 2c, never give estimates. They are a trap.
|
| As a developer, if you give an estimate, it will be questioned,
| second guessed, and then negotiated down to 1/3rd of its former
| self. Then when you do the work, it always takes twice as long as
| your _original_ estimate. The whole dance of estimation only
| succeeds to indoctrinate developers into the political
| environment of the organization, it turns developers into mini-
| managers over their own time and perturbs their productivity.
|
| Software engineering as a discipline has to move away from
| developer estimates. If you're articulating the work that needs
| to be done, estimating the work, then doing the work, the only
| function of your boss is to report on your execution. The demand
| for developer estimates are a consequence of managers trying to
| turn themselves into highly paid messengers with no skin in the
| game. I've seen what that does to developers: late hours and
| weekend work, horrible diet, stress, weight gain, divorces, it's
| ugly stuff. Don't let it happen to you.
|
| Have your boss make the estimates. They have access to resources
| you do not have. They can look at past performance on similar
| projects, they can look at actuals. That's their job. They need
| to do it.
|
| If they ask you for an estimate, "how long would it take to do
| x?" never start by saying "it would take about ...". Ask a
| question, something like "what do you mean by x?" Or "have you
| considered y, is that something we should be concerned about?"
| etc. keep doing that until you've gotten your boss to the edge of
| their knowledge. How they react will be telling. You end up
| providing more value in the long run because instead of giving
| your leadership a false sense of security, you'll be educating
| them about execution risk and setting your projects up for
| success by setting up future conversations to be constructive. If
| you do fall behind, you have ammunition to fall back on in
| meetings "last month I asked about x, because I was concerned,
| and now that concern has come up."
| beardedwalleye wrote:
| #2 and #3 are a bit at odds with each other. I certainly get
| tired of coming back to the same problematic code that's
| difficult to read and maintain. I appreciate others (and myself)
| for writing clean code.
| chasd00 wrote:
| I skimmed the bullets and pretty much agree with all of them.
| I've been doing software dev for 25 years or so so have been
| around the block a few times. There's a lot of good to go with
| the bad though, sometimes you meet incredible people who you just
| stand in awe of and other times you get to have a huge impact on
| someone and get to watch them blossom into something great.
|
| But yeah, the most painful is you rarely get a greenfield
| project, most of the time you're bolting on features to a shotgun
| shack of a codebase and praying for the best.
| usernamed7 wrote:
| > sometimes you meet incredible people who you just stand in
| awe of and other times you get to have a huge impact on someone
| and get to watch them blossom into something great.
|
| i can verify this was my experience at my last startup!
| foobarxyzzy wrote:
| I would also add:
|
| - stay humble. you are inherently no better than the guy who
| cleans the floors, even if you are paid more
|
| - your benefits package may rise very rapidly but it will hit a
| plateau unless you begin caring deeply about a domain other than
| mere software. You will need to start getting serious about
| something like finance, healthcare, automotive, etc
| BigJono wrote:
| > - stay humble. you are inherently no better than the guy who
| cleans the floors, even if you are paid more
|
| The guy that cleans the floors is doing a useful job, and doing
| a better job of it than I could do.
|
| The other programmers on the other hand...
| presentation wrote:
| RE estimates it's not about the time selected, it's about
| managing expectations. People need to know what they can expect
| from others in order to collaborate, the skill is in knowing when
| and how to communicate in the framework you're working in, so
| that everyone you're working with has reasonable expectations.
| You can get it wrong plenty so long as you manage people's
| expectations well.
| Bluescreenbuddy wrote:
| Approachability and emotional intelligence have been two of my
| greatest weapons in IT, not my technical skills. Humans are and
| always will be creatures of emotion, not logic. It sounds corny
| but I usually strive to be the guy people would enjoy having a
| beer with.
| edw519 wrote:
| I have another (more fun) way to say almost the same thing as OP:
| https://eddiots.com/
| lawgimenez wrote:
| Mobile development back in 2010-2014 is just full of greenfield
| projects and I am just so lucky to be part of it. Every month it
| feels like someone has a great idea of an app.
|
| There were no reviews back then in Play Store (formerly named
| Android Market), same with iOS, app store does not yet had a very
| strict review.
| moribvndvs wrote:
| Alleged Agile purists and Scrum Masters with a MEDIUMTEXT worth
| of Alliance certifications in their email signature who prattle
| endlessly about SWAGs, cone of uncertainty, "it's _just_ an
| estimation", tee shirt sizes, etc. will corner you with a demand
| to give the number of days it will take to do x with no necessary
| details or requirements, make you play planning poker with some
| other equally bewildered chump, ignore that and write whatever
| number they already had in their head into the roadmap which will
| be several months short of your guestimation, and then chastise
| you and your team for not delivering what they wanted even sooner
| than that, and before you're even done they start "knowledge
| transfer" and "switching to maintenance mode" so they can whisk
| you off to another equally fucked project; get ready for it.
|
| It's one big partially dysfunctional cargo cult where your
| toughest career problems are less frequently technical but
| political, interpersonal, and organizational.
| justaman wrote:
| MBAs and cert-chasers make the worst managers/scrum masters.
| Give me a former dev who had to code less because they got
| carpel tunnel or a hacker with only one book on agile
| methodology any day.
| schoenobates wrote:
| > your toughest career problems are less frequently technical
| but political, interpersonal, and organizational.
|
| I feel this statement is spot on.
| exabrial wrote:
| I disagree about the clean code. It's what defines engineering vs
| 'mere development'.
|
| Spending time on design up front and doing the smallest thing
| that could possibly work allowed you to move very quickly later.
|
| THAT gets noticed by management, and if you preach it long enough
| they buy in.
|
| Clean code is nothing more than just making sure a code base is
| fully consistent in its structure, self similar, or crystalline
| in its structure. Basically no cowboys or egos allowed: everyone
| writes things in the same manner and style, so everyone can
| understand it. It takes a lot of maturity from devs to do this
| and a lot of code reviews.
|
| I first saw this coding technique on a medical codebase that
| tested drug interactions, and later on a very much ununamed
| defense code base.
|
| Whatever the standards are ends up being s bit arbitrary, the
| actual value is 'everyone does one thing'.
| jelkand wrote:
| Are these hard to swallow? It feels like the author is pushing a
| particular tone when stating facts (with maybe a couple debatable
| points) that any software engineer would agree with.
| ibejoeb wrote:
| >I pause Slack notifications after working hours. I disable them
| on weekends.
|
| "I go home at the end of the day" -2010
| thanatos519 wrote:
| This is what makes co-op programs so great! They solve problem 1,
| allowing you to encounter these truths over time in the real
| world before you graduate.
| chx wrote:
| > College will not prepare you for the job
|
| no, it will not, it has a completely different role, the other
| name "University" gives you a very strong hint about it: what you
| learn in university is a universal way of thinking, of acquiring
| knowledge. The dirty secret is it doesn't matter at all whether
| you learn this by studying human anatomy or the stars blinking
| above. By the time you leave aside from very basic stuff your
| specific knowledge will be outdated anyways for multiple reasons.
| And your assignments are irrelevant to any job you will take, the
| primary criteria for your teacher when choosing assignments is
| the ability to grade you fairly and easily on a task with a known
| complexity.
|
| And there's no fast way to do this. We do not know how. There are
| a few, extremely few people who seem to be born with a mind honed
| to this but most people are not Terence Tao :D and actually need
| the five years of university to get there.
| danielovichdk wrote:
| I have been doing software professionally for nearly 25 years.
|
| Even if the points the author lays out are very true, don't you
| ever take them in as being true for you.
|
| One thing I have learned in all these years is that you can rule
| your own narrative in your job. And when patient, factual and not
| backing down when demanding answers on 'why', you will find out
| fast if you are made for being part of an often labour heavy
| workforce.
|
| Fact is that what the authors lays out, is not at all special to
| software engineering jobs. All industries are like that. We are
| not special in any way. And it starts by telling yourself that
| you are not special, but that you differ yourself by having a
| qualitative integrity - though that will take many years to get
| and always be in process.
| red-iron-pine wrote:
| > Fact is that what the authors lays out, is not at all special
| to software engineering jobs. All industries are like that. We
| are not special in any way. And it starts by telling yourself
| that you are not special, but that you differ yourself by
| having a qualitative integrity - though that will take many
| years to get and always be in process.
|
| Aye, a lot of the OP points sound like any white collar job.
|
| I've supported OT roles in Aviation and Railroads, and this
| sounds more or less like any engineering role I've seen.
| awill88 wrote:
| There's some good points on here that I might share with some
| tutoring students, esp about greenfield and how that's really a
| coveted thing in a social setting of engineers. I do think the
| tone should be worked on so it is less.. bleak. Like, I don't
| really remember being nervous about how long something would take
| me, unless I was concerned it was impossible to do to begin with.
| I also didn't have to deal with thinking about the job all the
| time, because I was doing it, which is a tongue and cheek way of
| saying if you want to succeed, work life balance might look
| different to you than to the peer next to you.
| sanderjd wrote:
| The greenfield thing is always funny to me - I really struggle
| with greenfield projects :) I don't like being faced with a
| blank page.
| SirMaster wrote:
| Hmm, Been in software development for 13 years not and I don't
| really agree with most of these.
|
| Maybe it's common, but I'd say certainly not a guarantee.
| beej71 wrote:
| I had 20 years in industry from tiny startups to megacorps, W2
| and contractor. Now I'm an instructor at a state university. So
| I've seen all sides. :)
|
| Re point 1, you'll learn a lot in the first few months in your
| job. The old adage that you'll learn more in the first 6 months
| on the job than you did in all of college has been around at
| least since I graduated nearly 30 years ago, and almost surely
| existed for decades before that.
|
| But you can't spend four years learning to learn and have zero
| impact from that. If you got through college and the only thing
| you have to show for it is a diploma, you didn't do it right.
|
| The author is correct that it's not everything you need. But it's
| only four years and it's tough to prepare a student for every
| single possible work environment on the planet. The only real
| option is a foundation, and they pick up the rest using their
| learning skills when they hit real life.
|
| Also, re "So don't get overly attached to your clean and elegant
| code. Focus on shipping the feature on time and bug-free."
| There's an interplay between all these concepts that I don't
| think the author acknowledges.
| ConnorMooneyhan wrote:
| Not to mention you might have to work on projects that are mostly
| divorced from programming entirely, like making plugins work
| together in WordPress.
| redleggedfrog wrote:
| I take issue with #3. The clean code is for _you_. Future you.
| You will be substantially more productive if your code is clean.
| You will end up being the "rockstar" (groan) because you can
| implement 2, 3, 5, 10(!) times faster on your clean code than
| your peers. I am living proof of this. And then when your
| managers and company realize you're the cash cow you can ask for
| absurd raises and get them. You are going to be hard pressed to
| do this with crappy code bases.
| sanderjd wrote:
| Not just future-you, future-everyone-on-the-team.
|
| And in my experience it isn't true that nobody in leadership
| appreciates this. I think it's easy to make the case that it is
| worth investing today to make it less burdensome for a team in
| the future, which may or may not contain the current team
| members, to evolve the software being written in the moment.
| This makes sense to everyone in a business, because the same is
| true of any business process.
|
| "Clean code" is not the only way to accomplish this; processes
| and documentation are other things you can do. But I also think
| it's easy to make the case that writing comprehensible code
| actually has the best lifetime return on investment. It isn't
| hard to do - indeed, it's often easier to ship working features
| with well-structured code, and it requires less future toil
| than documenting a process that requires working around poorly
| structured code.
|
| But of course often times there is a tipping point where
| further tinkering with making code "clean" is no longer net
| positive. But I think codenames that tend toward I dunno, maybe
| 95% cleanliness provide good value to an organization.
| throw4847285 wrote:
| Do other careers have such a vast gap between the platonic ideal
| and the actual lived experience? The way most people talk about
| software engineering, you'd think they were some kind of open-
| source warrior building entire applications from scratch when
| really they're on the Cancel Prime Membership Button Obfuscation
| Enablement team at Amazon.
|
| I think people like to role-play doing the job before it was
| professionalized because then it sounds less like you're a cog in
| a machine.
| perlgeek wrote:
| > Do other careers have such a vast gap between the platonic
| ideal and the actual lived experience?
|
| In the past few years I've got the impression that when I go to
| a doctor with a slightly unusual symptom, they are very much
| lost. It seems the average GP learned a whole lot at
| University, and 20 years later treats the same 50 common things
| (colds, cuts, high blood pressure, you name it) and doesn't
| really remember all the quirky and exciting stuff from uni.
|
| I'd guess that the more academic the education is, the more
| likely you fall into that pattern.
| Balgair wrote:
| I've interfaced with a fair few MDs in the US behind the
| scenes, so to speak.
|
| The site nearly every MD in the US uses is called UpToDate:
|
| https://www.uptodate.com/login
|
| It's not really for laypeople, so you can't poke around in
| there (check your alumni benefits though, many associations
| have subscriptions). But, to give you an idea, the site is
| pretty much a diagnostician. You can just plug in symptoms,
| patient history and demographics, and it'll give you nearly
| everything that you need to know. Lots of best practices,
| research papers, summary papers, testimonials, etc. It's
| effectively an AI for MDs, and it's good.
|
| What I'm trying to say is that your first instinct is
| correct: The MDs that you're going to really are in fact
| idiots that can't even be arsed to use a web form.
| buildbot wrote:
| Not sure why people are downvoting this - my partner is an
| MD and uses uptodate literally every few hours, when she's
| at home - I'm sure it's higher at the hospital/clinic.
|
| Some Doctors are checked out/lazy/make assumptions, just
| like everyone else.
| matheusmoreira wrote:
| Definitely. Resources like UpToDate are invaluable.
| Patient safety research proves it. Just double checking
| something to make sure reduces errors.
|
| Better not to do it in front of patients though. Many
| will assume you're incompetent if they see you doing it.
| Few will understand that you are a fallible human being
| who's using every possible resource to make up for it.
| michaelcampbell wrote:
| I can't remember how long ago, but I read or heard about a
| few studies that show you're better off going to a freshly
| minted doctor, at least in the US. They'll not have had the
| time to build a cynicism around "what they learned is all
| they need to know".
|
| I know Dr's learn a lot throughout their career, but after
| they get into a practice they just don't have the time they
| did in medical school (or won't spend the time), and the
| trajectory flattens.
| manicennui wrote:
| Or go to a doctor that is part of a top university system
| that does real research, such as Northwestern or Rush in
| Chicago.
| buildbot wrote:
| A research oriented doctor is going to have very little
| interest in anything but their research. So if you know
| you have a rare disease, sure. But most people do not.
|
| Go to a doctor from a hospital with acclaimed primary
| care, like University of Washington Medicine. Ranked #1:
| https://www.usnews.com/best-graduate-schools/top-medical-
| sch...
| tstrimple wrote:
| It's the same in software and likely every industry. Yeah,
| you still have plenty of very senior folks who have adopted
| the cloud and are building things in modern ways and on the
| bleeding edge of things. Then you've got the crusty HN
| types who think a Hetzner VM and Postgres is the best way
| to solve all the problems in the world and javascript is
| the bane of all existence. I've met the 50 year old
| developer who has written nothing but Java enterprise apps
| for the last 20 years who are all but useless outside of
| their niche, and a 60 year old developer who is still as
| giddy as a child while he's playing with code generation
| models. If technology is your passion, it's far easier to
| stay up to date and stay relevant. If technology is just
| your chosen career, you've got to intentionally put in the
| effort to stay up to date or risk becoming out of touch
| with the industry. There are passionate doctors and career
| doctors. Passionate home builders and career home builders.
| Etc. Etc.
| Rallen89 wrote:
| >'d guess that the more academic the education is, the more
| likely you fall into that pattern.
|
| of treating the most comments stuff and being lost? Would
| have thought the opposite, no, or am I misunderstanding
| waylandsmithers wrote:
| Yes- I've had the same experience... the same "Huh, that's
| weird" kind of unknowing response that I give my parents when
| their printer isn't working again
| ejb999 wrote:
| unfortunately, many (most?) doctors have simply become
| prescription writing machines - "got a problem? there is a
| pill for that", and if that pill doesn't work, we will try
| something else.
|
| Good luck finding a MD that actually wants you to be healthy
| and drug free - the system is setup to give you a
| prescription and hope that it works; doctors around me won't
| even broach the subject of suggesting you lose some weight or
| get more exercise or even just eat more healthy food - they
| just write a prescription to deal with the adverse affects of
| your poor lifestyle.
| matheusmoreira wrote:
| In my experience, it's the opposite. Day in day out I tell
| patients to exercise and eat better. Some people manage to
| change their lifestyle, get better and even get off
| medications such as statins. Many don't and medication ends
| up being the only thing keeping things under control.
|
| Then there are the patients who will destroy you on social
| media when you tell them to take some responsibility
| because that's "intolerance" of their morbid obesity.
| Plenty of people out there looking for easy pill solutions
| to everything.
| matheusmoreira wrote:
| General practice and primary care are all about what's
| common. It's designed to soak up all the easy stuff that
| makes up 80% of the cases so that the specialists can deal
| with the hard complicated 20% stuff. If a doctor can't help
| you, they should still know who to refer you to.
|
| Can you give an example of a slightly unusual symptom that
| stumps doctors?
| idopmstuff wrote:
| Both of those experiences exist, though - if you want to build
| applications from scratch, go join a really early stage
| startup. It's strange to me that people are surprised that when
| you're one of hundreds or thousands of software developers in
| an organization that you don't get to work on freewheeling
| projects based on what you want to do.
|
| Also, I don't think there's a platonic ideal of a software
| developer - there's a lot of mid-40s devs who have children and
| whose platonic ideal is a well-paying job with good work-life
| balance.
| madeofpalk wrote:
| Turns out most of those early stage startups are Cancel-
| Membership-Button-Obfuscation-As-A-Service startups.
| athorax wrote:
| I think a lot of engineering jobs have a similar disconnect
| KittenInABox wrote:
| > Do other careers have such a vast gap between the platonic
| ideal and the actual lived experience?
|
| Any NGO worker or nonprofit probably has this. Nurses, doctors,
| and veterinarians also.
| VirusNewbie wrote:
| >Do other careers have such a vast gap between the platonic
| ideal and the actual lived experience?
|
| I'm not paid boatloads of money for 99% of my work, i'm paid
| boatloads of money for the 1% of the time I have to do
| something very impactful. If using the right data structure for
| your 'cancel prime membership button' means a .1% server load
| reduction and 1% higher reliability, it's worth paying Joe Blow
| Amazon SDE 300k a year.
|
| It's the same with Doctors. Most of the time they say "take two
| Tylenol and call me in the morning". Or maybe they're stitching
| someone up in the ER and they're doing just as good of a job as
| a nurse. But once and a while they save lives with their
| decision making.
| matheusmoreira wrote:
| > Do other careers have such a vast gap between the platonic
| ideal and the actual lived experience?
|
| I used to really enjoy this blog from this american medical
| student. This guy seriously hated medical school and the worst
| part is I don't even blame him.
|
| https://web.archive.org/web/20101218031844/http://www.medsch...
| somsak2 wrote:
| #10 should be near the top. hugely important
| meling wrote:
| I think I'm one of those professors that actually do try to stay
| (somewhat) up to date with what the industry is doing. Sadly, the
| SE industry in my area (mostly consulting companies) isn't
| keeping up to date, so they complain why we don't teach our
| students C#.
| neonsunset wrote:
| Using C# _is_ staying up-to-date (because it is by far the best
| language if you want to be able to go both high and low level
| with terse syntax, and it runs everywhere too).
| yieldcrv wrote:
| > I put quiet hours on my mobile phone for my business emails
|
| I just don't install the email profile on my phone
|
| My job can send me a second phone just like they send me a second
| computer, so I can turn that off too
| perlgeek wrote:
| There's one source of bugs that the author doesn't mention: time,
| and how our understanding shifts with it.
|
| Sometimes the understanding of what a business object (or one of
| its attributes) represents sometimes shifts, over the course of
| several years. Sometimes, that shift is suble and easy to miss,
| like that it used to represent a desired state, and now more
| often represents an observed state.
|
| Sometimes, other ways to manage some objects come about, and of
| the original use cases of an object or table, only some (formerly
| niche) use case remains.
|
| Sometimes our use of language drifts, for example when a third-
| party tool is introduced that uses similar but not-quite-
| identical vocabulary.
|
| All of these can lead to formerly correct behavior now being
| obviously wrong. Sometimes it's hard to remember the context of
| the original implementation, and you ask yourself why anybody in
| their right mind would have done what you did back then.
| freeplay wrote:
| I've been a SWE for about 10 years.
|
| Here's my pros and cons:
|
| + Compensation is insane. I don't think there is anything else in
| the world I am qualified to do that would pay me nearly as much.
|
| - Deceptively long hours
|
| - Constant deadlines that are often solely dependent on you. If
| you are at the senior level or higher, there are often features
| that depend only on you. If you miss a deadline, several people
| up the chain will most likely know about it. There is no one to
| share the "shame" with. It's all on you.
|
| + Flexible schedule. Every place I've worked has been very
| accommodating (usually to the point of not caring at all) of
| family obligations, doc appointments, start time, etc.
|
| - Constant objective changes. Speaking from FAANG, things are
| constantly changing. You could be months into a feature,
| priorities shift, and they shelf the whole thing. Not to mention
| the re-orgs.
|
| Overall, I feel very fortunate to have this career. I often see
| folks my age grinding away at some soul sucking job and my
| gratitude intensifies. However, it's not all sunshine and
| rainbows. The nap pods and ping pong tables are just a recruiting
| tool, not part of day to day life.
| throw555chip wrote:
| > Compensation is insane.
|
| What?
|
| > Speaking from FAANG
|
| Oh.
| hotnfresh wrote:
| Comp's not insane in the rest of the industry, but _is_ just
| about the only non-management route to the 1960s-1990s style
| middle class that remains. It 's a lot of money compared to
| median income.
| madeofpalk wrote:
| Even outside of FAANG the pay is still quite generous, at
| least from my experience in.... US/AU/UK/etc
|
| You get paid so much for relatively so little. Housemate was
| a chef who's work was so much more demanding physically and
| worked stupid hours, and was paid a fraction compared to
| developers.
| throw555chip wrote:
| If a meal is returned by a customer, the restaurant doesn't
| go out of business.
|
| If a C programmer forgets a break statement, the entire
| western half of the US loses phone connectivity for several
| hours: https://news.ycombinator.com/item?id=34665023
| freeplay wrote:
| This is the rub right here. Huge mental overhead that is
| often not mentioned.
|
| Not only the potential for great consequence (think
| errant deployment in AWS S3 that takes out an entire
| region and costs the company millions), but the
| requirement to constantly be evolving and learning new
| things. Not only learning but being proficient at them.
| All while not forgetting the original stuff you knew.
| thorncorona wrote:
| > the requirement to constantly be evolving and learning
| new things.
|
| when is this not the case?
|
| there are no fields that pay well where stagnation is
| acceptable. not in (real) engineering, not in the
| sciences, not in legal, business, marketing, etc.
| madeofpalk wrote:
| Most developers are making are not C programmers
| responsible for half of US phone connectivity.
| freeplay wrote:
| I'm just saying, compare what you're making to the average
| person your age. Take into account the amount of debt that
| comes along with some of the professions requiring extensive
| schooling. Also consider the conditions and work life balance
| (ex: welders can make a great deal of money however they are
| often away from home for months and work 6-7 days a week in
| rough conditions).
|
| Even if you're not at FAANG, overall, we're making a lot of
| money working from a comfy chair with little to no required
| debt.
| Yhippa wrote:
| Have you worked with people at the same professional level
| outside of FAANG? There are a lot of companies outside of
| those BigCo tech companies that pay well without the
| stressors that you mention.
| netbioserror wrote:
| I dodged all of this hard by taking an interview with a smaller
| engineering-adjacent company. A lot of these points seem like the
| reality when working at a gigantic conglomerate that doesn't take
| its software arm very seriously. Mine does because the software
| analysis is the core product.
|
| 1) All of my previous practice and my Master's-level statistics
| and signals processing prepared me well for this job.
|
| 2) Out of the gate, my boss gave me free reign to greenfield
| replace a lot of old tools.
|
| 3) My clean code and the documentation around it is needed,
| because obfuscated and undocumented code is what previously shot
| this company in the foot, and is what I was replacing.
|
| 4) Everyone in the software part of the company is competent; the
| only issues come from outside our department.
|
| 5) We have one one-hour weekly meeting to talk progress and
| potentially connect on important points. Everything else we
| discuss as needed.
|
| 6) Estimates are rarely needed because I made the right choice of
| languages and tools. I can make changes or add features same-day
| or within a couple days. One longer-term project I'm on has no
| deadline; it's needed, but not urgently.
|
| 7) My choice of language and tools makes bugs easy to track down.
| Most of my issues are solving for engineering edge cases.
|
| 8) Not that I'm always certain, but uncertainty is never really
| an issue here.
|
| 9) I hard disconnect from my job, and my boss wants it that way.
| Nobody has my email or phone number. When I go home, I go home.
|
| 10) I've had soft skills my whole life, so I've never run into
| that issue.
|
| I didn't get the fabled six-figure starting salaries people
| everywhere seem to be chasing, but I've concluded those aren't
| truly real and were driven by $2 trillion money-printing
| valuations.
|
| If anyone is curious about my tools, I use Nim to analyze signal
| data and output analysis and reports; it's a CLI tool that puts
| out standardized data formats, which can be invoked by server
| scripts whenever needed. Most of our systems have already been
| overhauled to use it as the crux of our data analysis. I replaced
| a lot of old deliberately obfuscated C and PHP.
| taylorbuley wrote:
| > It's just an empty protocol to prove their purpose of existence
| in the company.
|
| Sounds like he came from a pretty bad development environment. I
| am sad to think this is what he communicated to young developers.
|
| These meetings can help to surface problems, provide a shared
| space to refine work as a team, create a plan against available
| resources... All of this helps developers move faster and ship
| more frequently.
| wnevets wrote:
| > 3) Nobody gives a f** about your clean code
|
| #3 should be that your definition of "clean code" is almost
| certainly wrong.
| NewEntryHN wrote:
| OP needs to change companies.
| dkarl wrote:
| > 3) Nobody gives a f** about your clean code
|
| This is true most of the time, but assuming your boss and
| coworkers are doing their jobs well (which is why it's not true
| most of the time) people will regularly communicate the things
| that are helping or hindering in their work.
|
| Of course, you might find that your perfectly clean code isn't as
| helpful as you expected, depending on what you see as "clean."
| You'll learn that people care about how quickly they can
| understand and use your code, and whether they can make changes
| without worrying about breaking things. That's all they care
| about, and that's what "clean" is supposed to serve and
| accomplish.
| jebarker wrote:
| > whether they can make changes without worrying about breaking
| things
|
| In my experience no coding standards or cleanliness can prevent
| this. The only sure way is testing on commit/PR.
|
| EDIT: A common failure mode I've noticed is that people only
| test the functionality they've added and not other parts of the
| system that may be affected.
| dkarl wrote:
| > In my experience no coding standards or cleanliness can
| prevent this. The only sure way is testing on commit/PR.
|
| I think that's an issue with how people define "clean." It
| isn't just about surface aesthetics. Think of a cooking
| appliance that looks "clean" in its design, that might win a
| designy design award, but accumulates gunk in hard-to-reach
| crevices because it was only designed to _look_ clean, not
| designed to be kept actually clean.
| jebarker wrote:
| Fair enough - it may be that I've never experienced "real"
| clean code. But I've worked with many good engineers and
| seen this problem repeatedly. However, no matter how
| unclean the code is a rigorous test suite will find many
| regressions.
| kinonionioa wrote:
| A modular architecture will prevent changes to one system
| from breaking other systems.
| PH95VuimJjqBqy wrote:
| hard disagree, there are definitely ways to prevent this,
| it's a matter of do developers even consider it?
| jebarker wrote:
| No, they don't. But that's the problem, you can't force all
| developers to consider these issues and adhere to coding
| standards. Sure, you can do reviews and then make them do
| that, but if they have to pass a suite of tests before it
| even gets to review then that's going to save everyone's
| time and train them to do it right.
| ska wrote:
| Coding standards an cleanliness are at the wrong level.
|
| What makes it easy to make changes, add features, find bugs,
| etc. is good _design_.
|
| Testing can help find problems, sure, but you can't test in
| quality (you can only, to a degree, test in robustness).
|
| The difference between a decent design and a mess is mostly
| what happens when your "simple, local fix" causes unexpected
| tests to fail. If your first reaction is "damn, guess we
| can't do that" three is a good chance you have a mess on your
| hands.
|
| Clean code (yes some of this is just taste) is mostly a
| symptom that people have been thinking about this stuff, not
| a guarantee.
|
| There is a corollary though, which is difficult. Quality of
| design and techniques used mostly put an upper bound on the
| complexity the system can have before it becomes
| unmanageable. If it grows long enough though, it will get
| there.
| justin_oaks wrote:
| > A common failure mode I've noticed is that people only test
| the functionality they've added and not other parts of the
| system that may be affected.
|
| This failure mode often comes from parts of the system being
| coupled when they shouldn't be, or it's not obvious that they
| are.
|
| Have you ever had a change to a logging statement break cause
| some other code to stop functioning? I have. And I was
| thoroughly disappointed by the person who made a logging
| statement have any effect outside of logging.
|
| Clean code needs to adhere to principles such as the
| Principle of Least Astonishment[0], otherwise code is bound
| to break when other people modify it.
|
| [0] https://en.wikipedia.org/wiki/Principle_of_least_astonish
| men...
| Tainnor wrote:
| I think the problem is that, while most people agree that badly
| factored code that drags down productivity is a problem, people
| can't agree on how to make it better. So, discussions about
| code quality get mired in subjectivity, often people can't
| agree and if anything changes at all, you agree to some half-
| baked compromise that doesn't really address any of the issues.
|
| I don't think how you can avoid that unless you find people
| that have similar ideas to you about how to write code.
| sroussey wrote:
| That subjectivity also changes over time. Just go back and
| look at some code of your own after a few years.
| Tainnor wrote:
| Oh yes, I totally agree. Some things that I used to write,
| I would find insane now.
|
| But it doesn't make the problem any less real. At my
| current job, I think our tests are really bad because they
| mostly don't test what really matters (also due to too many
| things being spread out across several services) and
| instead are coupled excessively to implementation details.
| That makes development slow and also means I can never be
| sure that my changes don't break something important.
| PH95VuimJjqBqy wrote:
| having done this, I generally think my old code is fine.
|
| When people say things like I this I always point out that
| this may be true for the first 2-5 years of you developing
| but if it's true 15 years in you're not actually improving
| you're just being mercurial.
|
| At some point your growth as a developer moves outside of
| code and you recognize that there's beautiful code,
| devilish code, and then a huge grey area where things are
| just fine even if they aren't how you would have personally
| implemented them.
| Tainnor wrote:
| Having been in the industry for 10 years, I would agree
| that after a certain point, your personal opinions about
| code style tend to change less and become more
| consistent, but I still run into enough other people that
| also have a lot of experience, yet seem to have entirely
| different views.
|
| Out of interest, what kinds of things would you consider
| "beautiful" or "devilish"?
| PH95VuimJjqBqy wrote:
| I read through the CLANG code back in the early days of
| its existence and found it to be quite elegant in its
| structure.
|
| devilish, I once came across where someone had
| accidentally written a FSM that used http redirects as
| the transitions between nodes. All to animate a progress
| bar for a job queue. It was so ridiculous it honestly
| took me longer than I care to admit to understand what I
| was seeing, who the hell expects to see that?
|
| OTOH, we have a codebase at my current employer that
| opens up a TCP socket to a service and passes pipe
| delimited strings. And you know what? I give the thumbs
| up to that. Why? The service it's communicating with is
| an old C++ service that was written around the time that
| XML started coming onto the scene. That's how you did
| things back then and it works perfectly fine, albeit it's
| probably not the most familiar to younger developers.
| siva7 wrote:
| I wish people would understand this better. "Clean code"
| doesn't exist. You should define (and automate) quality gates
| for your code base as a regular team excercise. I've seen
| enough teams not even having a common agreement on what a code
| review is and then trying to do them. When regularly wondering
| on a code review if change X meets the subjective taste of
| reviewer Y or even getting into fights you know somewhere
| something went wrong in team culture.
| dkarl wrote:
| Tests matter, but elegance and simplicity matter, too. Tony
| Hoare said, "There are two ways to write code: write code so
| simple there are obviously no bugs in it, or write code so
| complex that there are no obvious bugs in it." All code needs
| module-level or API-level acceptance tests so that anyone can
| change it and deploy it with confidence, but well-written
| code needs fewer low-level tests of implementation details.
| deathanatos wrote:
| I agree with what you wrote, but I've worked with people who
| balk at even automatic gates. "Pass pep-8, as enforced by
| pycodestyle" was practically too much for one coworker I had,
| who, when it was pointed out in review that " _the automated
| CI step was failing_ , can you please make it green?", would
| fix like one violation, then just ping their reviewer? And
| around the mulberry bush we went. Various odd arguments like,
| "well, my IDE has pycodestyle built in, and it's fine" (it
| seemed like his IDE had its own, separate, lenient config?
| ... but like, nobody cares about _your IDE_ ...?) etc.
|
| At $different_employ, there was lots of thrashing of teeth
| pertaining to `yarn audit` running against the codebase, and
| failing people's builds. Some people fought tooth and nail to
| get it to not fail the build, because they didn't like that
| their new feature, which didn't introduce any vulns. per se,
| was failed. Later, other people did much gnashing and wailing
| over being "confused" because the yarn audit step was red-X,
| and they were confused as to why it was breaking on their
| feature branch. It wasn't: it was failing, but marked to be
| ignored, so the build continued. Other, required steps, were
| failing. (And were also marked with red Xs.) This was "all
| too confusing", and it was petitioned for yarn audit's CI
| step to just "fail" with a green checkmark. You can imagine,
| I'm sure, how many vulns. were addressed after that point.
|
| I've also worked with devs who are just amazing, and aside
| from being brilliant in how they architect their code/systems
| in the first place, ... they have a definite tendency to view
| lint errors as just "oh, oops, silly me _fixed_ " and just
| Get It Done.
|
| QC is hard.
|
| (Regarding our audit step, too: we also had an ignore list.
| You _could_ just add the vuln. to the ignore list, and that
| would technically placate CI. Obviously not the _best_ ...
| but CI didn 't _demand_ that you fix whatever the issue was.)
| MattGaiser wrote:
| > Some people fought tooth and nail to get it to not fail
| the build, because they didn't like that their new feature,
| which didn't introduce any vulns. per se, was failed.
|
| Well, here is the problem this introduces. Who is supposed
| to fix this and which PM's bucket of time does it come out
| of? This implementation just makes it seem like the answer
| is "whichever team is unlucky enough to make a PR when it
| is discovered." The perverse incentives of that are
| enormous.
|
| > You can imagine, I'm sure, how many vulns. were addressed
| after that point.
|
| This tells me that the responsibility isn't specifically
| assigned. This seems to be the broader issue, with the
| audit in the pipeline a managerial attempt to get vulns
| somehow fixed without doing the work to figure out how they
| will be fixed and who will do the work.
|
| Someone actually needs to be responsible for it and be
| given time to do the changes. It seems like this was not
| done.
| deathanatos wrote:
| > _Who is supposed to fix this_
|
| The team of eng responsible for the code against which a
| vuln. has been detected, would be my answer.
|
| > _This tells me that the responsibility isn 't
| specifically assigned._
|
| Well, no, for the very reason you've highlighted: PMs
| will be damned to have that time come out of their
| bucket. That _is_ a problem, and I rather doubt this
| subthread 'll solve the idiocy that is PMs.
|
| Nonetheless, if we accept that vulns. are something the
| industry should pay attention to, i.e., that "keep stuff
| using secure versions of dependencies" is actually a best
| practice the industry should adhere to, _someone_ has to
| triage the audit report, and then _someone_ yet has to do
| the deed of correcting it.
|
| Yet both your comment & a sibling have advocated the
| position of "no, drown the test result, don't block
| builds". If builds aren't blocked, there is zero impetus
| towards ever fixing vulns., so they don't get fixed,
| ever. You cannot, IMO, ignore human nature when setting
| up these kinds of QC checks in CI: _if you make them
| optional they 're as good as dead_, cause people are
| lazy.
|
| You're missing the larger point of my comment, too:
| _there is no sensible setting for that CI step_. Say I
| don 't care about _what_ the CI step does, say I don 't
| attempt to take a position in this idiotic debate. I
| can't: literally _any_ configuration boils down to one of
| two cases: a.) we 're flagging the problem, and devs
| don't like that and whine and complain or b.) we're
| ignoring the problem, and security people _claim_ they
| don 't like that, and whine and complain.
|
| I think you're also forgetting how software is actually
| developed in the wild by many companies: this example,
| like so many, use a "monorepo". _I_ don 't like this (I'd
| argue for single-purpose repos, and it'd be obvious who
| the owner of a vuln. is, since the whole repo is only
| owned by one team.) but nonetheless I'm pretty
| consistently outvoted on this point, and the majority of
| firms out there seem to go the monorepo route. So, in a
| monorepo, "who" is responsible for a vuln. against a
| third-party dependency? (It _can_ be figured out, but the
| answer is certainly not as straight-forward anymore!)
|
| (Single-purpose repos aren't without issue here either:
| often I find in _that_ case that establishing these sorts
| of "common" CI steps to be hugely problematic: you sort
| of have to c/p a lot of code between repos, keeping that
| step's code updated is then a PITA, and many CI systems
| lack good support for "use this common step, perhaps not
| even located in this repo".)
| yjftsjthsd-h wrote:
| > Some people fought tooth and nail to get it to not fail
| the build, because they didn't like that their new feature,
| which didn't introduce any vulns. per se, was failed.
|
| Well... yeah? They're working on a feature and get
| arbitrarily told that they're not allowed to merge the
| feature until they go fix some completely unrelated
| vulnerability problem. How is that reasonable?
| f1shy wrote:
| Anything that can be automated for QC, should be. But if you
| want to completely eliminate subjectivity, you have to stop
| working with SW. There is nothing an will never be, something
| that can test if code is really easy to understand. Had you
| such tool, the tool will be able to code by itself.
| koolba wrote:
| If nobody gives a fuck about clean code in your org then you
| really need to find a new org. Perfect need not be the enemy of
| good, but if nobody cares at all then the problem will just get
| worse over time. Get out while you can and surround yourself
| with people and an org that take pride in their work.
| docmars wrote:
| Completely agree. It's the equivalent to keeping a tidy
| workspace with others in mind. Teams should spend time
| narrowing down coding styles, naming conventions, and general
| rules together over time, and stick to them.
|
| As new people are onboarded, stick with those rules but have
| periodic moments where you solicit feedback from your team on
| the approach and make changes.
|
| It really does help to have a team agreeing on these things
| collaboratively, and ideally having a more senior person
| enforcing it during code review where it's reasonable.
| AdamN wrote:
| It's basically like a construction site - plenty of low
| rent projects are done in a totally disorganized "get 'er
| done" way. You won't see that as much for a high value
| construction site with top tier vendors and workers who
| value their craft.
| koolba wrote:
| This is a great analogy.
|
| There's some related thoughts on safety practices that
| would be readily apparent to someone on a job site that
| apply to software as well. In my personal experience,
| people who don't take pride in their work are the same
| ones that end up creating unsafe situations. The software
| parallels are easy to imagine.
| randmeerkat wrote:
| > It's basically like a construction site - plenty of low
| rent projects are done in a totally disorganized "get 'er
| done" way. You won't see that as much for a high value
| construction site with top tier vendors and workers who
| value their craft.
|
| The Salesforce tower in San Francisco begs to differ: htt
| ps://www.popularmechanics.com/science/a29329189/salesforc
| ...
| TeMPOraL wrote:
| > _for a high value construction site with top tier
| vendors and workers who value their craft._
|
| Is it really that, or are there just so many parties
| involved, that a heavy bureaucracy/coordination layer is
| required to keep the project from collapsing on itself,
| and this happens to manifest as everything looking neatly
| organized and structured?
| bumby wrote:
| This and construction is governed heavily by codes (in
| the US, at least). This constrains how much freedom
| builders have to design any-which-way they want.
|
| But to the OPs point, there is a stark difference in the
| quality of work between tradespeople who respect their
| craft and those who look at it as merely a means to a
| paycheck.
| mozman wrote:
| Is there such a thing as clean code? What's perfect now can
| change at any moment.
|
| New business or acceptance criteria, architectural changes,
| and other human created obstacles.
| f1shy wrote:
| What exist is code that can be maintained, and code that
| just cannot (in practical time). There is no sharp cut, is
| a continuum. But if nobody cares, at some point it grinds
| to a halt.
| bluGill wrote:
| Software has been around long enough that many companies
| have been burned by bad code and so they are willing to
| give training and time to making it better. While there
| are trade offs, spending several years of no features
| while engineering rewrites the whole thing isn't
| acceptable.
| AdamN wrote:
| Extensibility is the term that speaks to this situation.
| Extensible code, updated by skilled developers, will allow
| for radical business logic changes without sacrificing the
| quality of the code over time.
|
| It's like a skyscraper. The critical structural stuff is
| fixed but the architects and engineers try to minimize
| those pieces and create flexible spaces that can either be
| high density cubicles, enclosed offices, a cafe, etc...
|
| Eventually it's true that you have to tear it all down and
| there's nothing wrong with that - a good developer will
| know when that makes sense based on the needs of the
| stakeholders and make that recommendation.
| mejutoco wrote:
| I like it, but I think how easy it is to replace is more
| important than how easy it is to extend. Otherwise it
| might end like those massive class hierarchies instead of
| a function.
|
| For me, pure functions and enforced types do the trick.
| PH95VuimJjqBqy wrote:
| the word 'care' is doing a lot of work here.
|
| Not all code is created equally, not all code needs to be
| clean or have a lot of time spent on it. Many times those who
| "care" about clean code have difficulty understand when it
| is, and isn't appropriate.
| grepLeigh wrote:
| I agree with this. The metaphor I use is restaurant kitchens.
| Some kitchens are permanently greasy and look like a bomb
| went off. The best 5-star kitchens are a whirlwind of
| constant cleaning and mise en place.
|
| "Clean code" is useless when it's an artistic aesthetic, but
| operationalizing the sense of "everything has a place, clean
| up as you go" has concrete value. You can spot teams that
| DGAF vs. teams that treat their responsibilities like a
| 5-star kitchen. In both cases, it's "just" a job, but that
| doesn't equate to carelessness.
| winternett wrote:
| There is often no better feeling of leaving a job where
| spaghetti code is a constant problem. I've worked on projects
| where co-workers took numerous short cuts that I'd regularly
| have to fix months later after they ditched their role. There
| is no real way to fix the problems of that kind because
| companies that emphasize proper testing and clean code simply
| don't weather tight deadlines and cost cutting that the rest
| of the industry imposes on everything, that's why there is
| often no better feeling of leaving a job where spaghetti code
| is a constant problem, :P
| lazide wrote:
| Like with many of the examples in the replies - they may not
| care about how clean your code is, but they sure as hell care
| (and notice) if they're constantly having to untangle
| someones shitty code after it broke production _again_.
|
| It's about where you are at relative to the median in the
| group, typically, not about any absolute standard.
| manicennui wrote:
| The real problem is that "clean code" is completely arbitrary
| and if you ask 10 software engineers you'll get at least 5
| different answers because this really boils down to
| preferences.
| ctvo wrote:
| > The real problem is that "clean code" is completely
| arbitrary and if you ask 10 software engineers you'll get at
| least 5 different answers because this really boils down to
| preferences.
|
| I disagree. I'll take a bet that given 10 experienced
| software engineers (we can define what this means -- title,
| years of experience, familiarity with language idioms, etc.)
| they'll mostly agree on samples A, B, C, ... of code if it's
| "clean" or not.
|
| Code doesn't have to follow my preferred design pattern to be
| clean. The bar is don't be shitty, and I'll know shitty code
| when I see it[1].
|
| 1 - https://www.wsj.com/articles/BL-LB-4558
| gizmo wrote:
| I really doubt there is any such consensus. Some people
| really care about superficial code quality (good variable
| names; short functions; consistent formatting and
| documentation; compiles without warnings). Other
| programmers care mostly about architectural quality
| (shallow call stacks; correct data structures; few
| dependencies and little scaffolding).
| f1shy wrote:
| As stated in the previous comment, if you give code from
| group A to group B, they will tell you "I would prefer
| this and that, but still seems clean to me"
| gizmo wrote:
| I don't agree. I know what the previous comment said.
|
| Modern C++ codebases that make extensive use of
| templates, inheritance, exceptions, type coercion,
| closures are considered clean by many because the code
| looks nice. But code like that can be a nightmare to work
| with, because of long compile times, spooky action at a
| distance, etc.
|
| Take these two files from LLVM:
|
| https://github.com/llvm/llvm-
| project/blob/main/libcxx/includ...
|
| https://github.com/llvm/llvm-
| project/blob/main/libcxx/includ...
|
| Is this "clean code"? I'm confident there will be
| absolutely no consensus.
| SideburnsOfDoom wrote:
| I disagree. While one can argue pointlessly over which code
| is the cleanest, it's very obvious when the code has a
| complete absence of it. I think of some 3000 line classes
| that I have met and done battle with.
|
| The sibling comment that talks about "how quickly they can
| understand and use your code, and whether they can make
| changes without worrying about breaking things" is on the
| right track.
| kinonionioa wrote:
| Writing good code requires good taste. Taste is subjective
| and cannot be easily codified. That doesn't make it
| arbitrary. Ask ten people about their favorite movie and
| they'll name ten different films, but I'd wager no one will
| say "Gigli".
| bumby wrote:
| "All [clean codebases] are alike; each [ugly codebase] is
| [ugly] in its own way."
|
| -Leo Tolstoy
| esafak wrote:
| No, it is not. That is like saying art is objective so we
| can't say if anything is good or bad.
|
| Don't you know a bad API, variable name, or architecture when
| you see one?
| doctorpangloss wrote:
| I agree with you. From experience, this pain is a red
| herring, it's symptomatic of a specific kind of change: new
| features or bug fixes that require tight coupling of
| previously-authored-as-decoupled things. Clean code,
| architecture, whatever - it always falls over in the
| specific transition from decoupled-to-coupled.
|
| Why do programmers hate making those changes? They always
| require tossing out a lot of existing code. So I guess I
| could say the antagonist is inertia. Certainly has been my
| experience interfacing with vendors and BigCo developers.
| If you have the ability to suppress this feeling, to delete
| stuff that works but is not correctly coupled to the new
| problem, you will thrive regardless of the architecture.
| bumby wrote:
| The heart of your comment is true, but good organizations
| establish a set of standards for how they define clean code.
| At that point, it's no longer arbitrary.
| oweiler wrote:
| Devs also overestimate the difference their "clean code"
| actually makes. Architecture is much more important.
| kbenson wrote:
| Sometimes what some people think of as clean is really more
| "optimized for the current state or the project." that seems
| fine, until next month the new feature requires that "clean"
| code be ripped apart because it encoded too much of the current
| program state as assumptions in how it worked.
|
| Be careful not to conflate clean code with premature
| optimization. Clean code is easy to read and follow and works
| in obvious ways, it isn't _necessarily_ the fastest or most
| efficient code and nor does it mean it has to use deeply nested
| knowledge of how the system works to function in ways that are
| non obvious to new readers.
| jiggawatts wrote:
| This is why I go out of my way to praise good work loudly and
| publicly when I see it.
|
| If everyone merely _accepts_ good work silently, but talks
| about bad work all the time, then political focus within the
| org will shift to bad teams and bad people. At the extremes
| I've seen this result in the worst people getting promoted to
| the highest positions because they were infamous. That's the
| same as being famous.
|
| Think about Trump: he got elected because nobody could shut up
| about him, so to a lot of voters didn't know anything about any
| other candidate. They voted for the one they recognised.
|
| "He may have his flaws, but he's not that bad." is something
| I've heard at work and in the public sphere.
|
| You're immune to this effect, you're about to say?
|
| Name five good things that Hillary has done.
| meiraleal wrote:
| > Name five good things that Hillary has done.
|
| You got me absolutely confused here. There are 5 good things
| she had done? I think this proves that a bad alternative can
| get anybody elected.
| jiggawatts wrote:
| I think you've just confirmed my point.
|
| She's worked in public service for decades and has done
| many good things in that time. Most people can't name any.
|
| Everybody in the world can name five (fifty!) bad things
| Trump has done.
|
| That's why that man lives rent free in our heads. That's
| why everyone knows his name. That's why he got many of his
| votes: he's _recognisable_.
|
| This effect has nothing to do with any specific
| politicians.
|
| It happens in workplace settings also. The quiet achievers
| get overlooked. The loudmouth screwup gets attention and
| even promotions.
|
| I'm old enough to have seen this play out over and over
| again at every scale.
| meiraleal wrote:
| Or maybe she is as bad as the voters took her for and you
| are delusional.
| jiggawatts wrote:
| You're missing the point.
|
| The point is not whether Hillary is good or bad.
|
| The point is that most people are unable to remember good
| things that even very famous career people have done,
| despite this information being in the public record. It's
| just not covered, repeated, and as _memorable_ as bad
| things that people have done.
|
| You're focused on "Hillary bad!", not realising that
| _that 's the point I'm making_. You can only _remember_
| bad things.
|
| The exercise is to see if you can name good things. You
| can't not because she's unadulterated pure evil, but
| because good things are not as memorable in general.
|
| Try for a moment to rise above your primitive animal
| tribal instincts and think like an anthropologist.
| sandman008 wrote:
| I don't agree with your Trump example, but agree with your
| main point.
| diyseguy wrote:
| I honestly wish there were some kind of rating system for
| employers where their code quality is rated on a scale of 0:
| spaghetti/lasagne precious mess written by a sacred primadonna
| chief engineer who must be deferred to reverently and takes a
| year or more to get the hang of, to 10: fully unit tested,
| integration and pre-prod environments, minimal pagers needed,
| competent QA, etc.
| HumblyTossed wrote:
| > You can forget that your boss will tell you: "Congratulations
| on writing this elegant and clean code, I am gonna give you a
| raise!". Quite the opposite, nobody cares about your clean
| code.
|
| > Don't get me wrong, people will expect you to write good and
| clean code. Still, you will rarely get any praise for it.
| Except sometimes from your colleagues who will review your
| code.
|
| If I can read your code, I don't give a frog's butt if it's up
| to the nose in the air crowd's standards. That just isn't what
| is important to a business that actually wants to survive and
| make money. It's crazy, those same blog heads are the ones who
| are always so quick to advocate for a "total rewrite" every 6
| mos. They think all this nonsense makes them Pros.
| AceJohnny2 wrote:
| > _Of course, you might find that your perfectly clean code isn
| 't as helpful as you expected, depending on what you see as
| "clean."_
|
| To add to this, people will have different opinions on what is
| "clean". In fact _you_ will have different opinions on what is
| "clean"!
|
| I've lost count of the times I've written some code, only to
| come back _the next day_ and re-write it into a "cleaner"
| version.
|
| Like writing an essay, it takes time and iteration, and
| sometimes there just isn't a stable solution. This has somewhat
| helped me in just writing the damn code (but my ADHD brain
| still habitually reaches for "perfection" over "get it done")
| justin_oaks wrote:
| I remember a time in my career when I looked at some code and
| I was truly impressed by whoever had written it. It was
| different from the code I was used to finding in the
| company's codebase. The intent was clear, it was efficient,
| etc. I looked into the source code history to see who wrote
| it. I was surprised to find that I had written it, but I'd
| entirely forgotten writing it. I got a good laugh out of
| that... but I was mildly disappointed that I couldn't praise
| someone else.
|
| Of course this is the exception rather than the rule. I've
| done a lot of revision on my code. If you don't look back on
| your code and think of ways it can improve then there's a
| good chance you're not learning.
| foobazgt wrote:
| "If you don't look back on your code and think of ways it
| can improve then there's a good chance you're not
| learning."
|
| I say this exact same thing to junior engineers who are
| acclimating to code reviews and might be suffering a bit
| from imposter syndrome.
| 9dev wrote:
| I love these rare moments when I think of solving some
| problem, figure out what I need to do and where, proceed to
| get started - only to notice I have already done this
| exactly the way I had planned, but forgot about it.
| norwalkbear wrote:
| Especially true in game dev
| rstuart4133 wrote:
| > > 3) Nobody gives a f* about your clean code
|
| > This is true most of the time, but assuming your boss and
| coworkers are doing their jobs well (which is why it's not true
| most of the time) people will regularly communicate the things
| that are helping or hindering in their work.
|
| Code reviews seem to be the norm now. I'm struggling to see how
| that aligns with everybody not giving a fuck about code
| quality.
|
| Maybe it was true. 40 years ago, we noticed code gets read many
| more times than it is written. It took us a long while to do
| something about it, but now insisting programmers produce
| readable code is easy to read where the industry is at.
|
| It's not just "the industry" either. Try submitting a bad piece
| of code to the Linux kernel and see how many fucks they give
| you. It's the same for an open source project that does code
| reviews.
| r00fus wrote:
| > Of course, you might find that your perfectly clean code
| isn't as helpful as you expected, depending on what you see as
| "clean."
|
| Yes, readable code is the winner. Not "ultra compact" or "so
| elegant you can't understand it". I once refactored an
| elegantly written but heavily opinionated codebase for a large
| feature - and my goal was to hand it off without any downstream
| complaints - so I doubled the LoC and the team that received it
| was very happy with all the non-terse logic and detailed
| comments (good code is self-explanatory on how it works, but
| not often on _why it 's there_)
| lars512 wrote:
| _The majority of them are forced by a person who is organizing
| them because that 's the only "work" that that person is doing._
|
| This a pretty cynical and unproductive way to think of meetings,
| management, and the essential task of coordinating people's
| efforts.
|
| Isn't it also your responsibility, increasing with seniority, to
| make sure that the team's time is used well?
| karmakaze wrote:
| I don't consider any of these to be 'facts'--I'll save you the
| click (unless you're curious): TL;DR
| 1) College will not prepare you for the job 2) You will
| rarely get greenfield projects 3) Nobody gives a f***
| about your clean code 4) You will sometimes work with
| incompetent people 5) Get used to being in meetings for
| hours 6) They will ask you for estimates a lot of times
| 7) Bugs will be your arch-enemy for life 8) Uncertainty
| will be your toxic friend 9) It will be almost impossible
| to disconnect from your job 10) You will profit more from
| good soft skills than from good technical skills
| Conclusion: Software development is not a dream job.
| cooljacob204 wrote:
| Honestly sounds like the author has only worked at toxic
| places. I can't relate to half his points.
|
| Software development certainly is a dream job for me.
| karmakaze wrote:
| Personally this _is still_ my dream job and has been for 40
| years.
|
| The only one that's had any impact was 'incompetent people' (if
| they're in charge/lead), in which case I've switched teams or
| companies.
|
| As for (3) or (7) if you value a job well done as do your
| peers, then it's its own reward and I only care that I'm given
| (or can make/take) the time to do a better job than management
| knows is good for the company.
| codr7 wrote:
| It's not a bad job if you have what it takes, but the reason
| we're paid a lot of money is that many couldn't force themselves
| to do it even if they wanted to.
|
| There's a lot of responsibility, uncertainty and frustration.
| Very often we're doing something that no one did exactly the same
| way before, which means there are no clear answers and no one to
| delegate responsibility to.
|
| Maybe not so much in a junior position; but the more senior you
| get, the more of that you'll have to deal with.
|
| I agree about soft skills, learning to communicate well and deal
| with other people is a big part of it. Half the job is really
| more about diplomacy than technology.
| elteto wrote:
| > It's not a bad job if you have what it takes, but the reason
| we're paid a lot of money is that many couldn't force
| themselves to do it even if they wanted to.
|
| You make it sound like we toil away every day, almost as if we
| were breaking rocks or hammering iron. We don't. We have cushy
| and sedentary jobs that many could do and even more would die
| to have. Most LOB software development is not special and not
| that complicated. We don't create unique works of art in every
| project we work on, although the occasional piece of code does
| tickle the brain.
|
| There are many software developers working on much more complex
| things (compilers, OSs, high-performance computing, firmware,
| rockets, etc) but those are in the minority. And I firmly
| believe that anyone with enough training and experience can
| write OS code, or compiler code, or firmware, etc.
|
| > There's a lot of responsibility, uncertainty and frustration.
|
| I'm not going to say there isn't because there's certainly a
| lot of that, but it's a small price to pay for how good we have
| it. We also, as an industry, don't deal with more or less BS
| than other white-collar, office jobs.
|
| I recently had a conversation with a friend going through her
| (medical) residence: 12+ hour shifts several days in a row,
| combining hospital work with lectures. Nurses have it even
| worse. We (software developers) should be very grateful.
| manicennui wrote:
| Our jobs might not be physically demanding, but many of us
| are mentally exhausted every day. I don't work an insane
| number of hours, but the expectation is always that I'll
| figure out a way forward with limited information and a team
| comprised of both competent and incompetent people who mostly
| want to be told what to do. In the vast majority of software
| engineering jobs, writing the actual code is trivial.
| elteto wrote:
| But the same could be said of any white collar job with a
| modicum of complexity, no?
|
| I'm not denying what you are saying. I'm just not convinced
| it's different from other professions.
|
| I've had the opportunity to work with both mechanical and
| electrical engineers. They deal with the same office
| politics and other BS we deal with.
| manicennui wrote:
| I think in most organizations/teams, there are a small
| number of people who are doing most of the thinking, so
| yes, it is probably the same in all kinds of professions.
| My objection is mostly to the idea that jobs that aren't
| physically demanding are all comfy and not exhausting.
| codr7 wrote:
| True, it's more mentally demanding than anything else.
|
| And it is a good job, no doubt.
|
| Point still stands though.
| elteto wrote:
| > True, it's more mentally demanding than anything else.
|
| This is just not true. Going back to my example, doctors
| and nurses have more mentally _and_ physically demanding
| jobs.
|
| > Point still stands though.
|
| It doesn't. There are harder jobs, both mentally and
| physically. And most software development is generic and
| not that complex work that a lot of people could do.
|
| We are only snowflakes in the sense that we think we are
| special, and that comparatively we have very nice salaries
| (at least in the US).
| PH95VuimJjqBqy wrote:
| most doctors and nurses work off of mostly rote
| knowledge, software developers not nearly as much.
|
| it's an apples and oranges comparison.
| throw555chip wrote:
| > We have cushy and sedentary jobs that many could do and
| even more would die to have.
|
| Wrong, are you a manager in disguise?
| charles_f wrote:
| Its good to share your experience with new comers, I agree with
| some of it, there's a lot of stuff that's debatable, and I
| struggle to present my own experience as "truth" to begin with.
|
| > As someone who spent a lot of years in this industry
|
| Amazon calls qualifiers like "a lot" "weasel words", because they
| hide the information into a subjective expression. I had to go to
| the authors resume to understand what's "a lot" and it seems that
| it's 8 years. That's certainly more than average when you
| consider that the number of devs double every 5y, but I don't
| consider that "a lot". I have more than double that, and I still
| don't call that "a lot". I still have massive realization about
| work every now and then, which prevents me to establish "truths"
| given that it's all just perception. Side note: I tend to
| disconnect a little as soon as someone starts a sentence with "as
| a X", because they're trying to use their qualifiers as proof of
| what they say.
|
| > College will not prepare you for the job
|
| I feel like my own college prepared me well.
|
| > The majority of software engineers hate meetings. But remember
| that your job is also to communicate about things openly and
| proactively.
|
| I hate most meetings because they're useless. Half of the
| meetings I go to exist because a) someone does not like reading
| so they want me to read the status I gave in an email b) cargo
| cult c) because its more convenient for a single person to waste
| everyone else's. It's great that we can have meetings, some are
| productive, but in a software company that ships software,
| protecting the time of people who _actually_ write the software
| seems like a good idea.
|
| > Nobody gives a f** about your clean code
|
| In the companies you went to, maybe. I give a f** about clean
| code, because once in a while I am gonna get called at night
| because stuff's broken, and I don't want that to be because of
| your shitty code. (also, I rarely saw a college graduate produce
| clean code, it seems to be something that you need to have
| experience to do).
|
| > You will profit more from good soft skills than from good
| technical skills
|
| There's truth in there, it's important to develop your
| communication and presentation skills. To be fair a lot of my
| graduate year at college was around that so, once again, I felt
| prepared. Saying that you will benefit more from that than tech
| skills is against a stretch that will vary based on where you are
| at on both sides, and generally speaking it pays more to be good
| at what you are being paid for.
|
| > It will be almost impossible to disconnect from your job
|
| Strong disagree, and I don't think that this is a message you
| should transmit. Funnily I think I pivoted my point of view on
| that topic around the experience level of the author. I think
| it's a tendency of your early years, when career is your
| priority, to always prioritize career. Later, when you find other
| things you enjoy, disconnection from work is entirely possible.
| Don't take your computer when you leave for vacation. Be strict
| about not communicating after hours. Dont reply to your phone (I
| don't even have work emails on my phone). If you really love your
| job and spending more time in it is your hobby, go for it. If
| that's not the case, learn to disconnect.
| photochemsyn wrote:
| This is distorted thinking at best:
|
| > "This may be a shock for some new folks, but it makes perfect
| sense. As a software engineer, your primary task is to generate
| value for users. Writing code is just a step that accomplishes
| that goal."
|
| No other engineering discipline thinks this way. An aviation
| engineer's primary concerns are that the thing they're building
| is (1) safe and (2) efficient. Whether or not that product is
| profitable will depend on marketing and competition at a whole
| other level. It's NOT the engineer's primary concern. This is
| also true for electrical, chemical, civil, etc. engineering.
|
| If there are a lot of software engineers that think this way, all
| that means is that the discipline is still in its infancy and
| hasn't adopted the kind of engineering standards that others have
| had to over time. Maybe the kinds of standards and regulations
| applied to sellers of electrical devices should be applied to
| every company that sells software?
| yoyohello13 wrote:
| I have never encountered a profession that complains as much
| about their job as Software Engineers. I've worked many jobs in
| my life: restaurants, construction, teaching, IT Support and so
| far the best one has been software development. Every job has its
| annoying BS. I get it's not for everybody, but at least I get to
| solve puzzles all day instead of digging post holes or dealing
| with shitty customers.
| spir wrote:
| Pete Davidson joked that depression is a rich person's
| condition because it implies you have a life you shouldn't be
| depressed about. Same with software engineers?
| tstrimple wrote:
| I know mental health issues and suicide attempts correlate
| much more strongly with folks lower on the socioeconomic
| ladder, but when I was poor I was too busy to be depressed in
| the same way I am today. Now my life is far easier, yet also
| somehow much more depressing.
| PH95VuimJjqBqy wrote:
| having grown up extremely poor, I agree with this
| sentiment.
|
| But it's also more than that. I hate using this word but I
| think it applies here.
|
| Poor people don't have to the privilege to stop and whine.
|
| - When I was a teenager I had a flat tire and the spare was
| flat. I knew of a tire shop a few miles down the road so I
| pulled the tire off my vehicle and walked it the several
| miles to the shop. The shop was closed because the guy had
| called in sick. It was another 15 miles to town, so I
| started the walk. Thankfully someone took pity on me and
| picked me up after a couple of miles.
|
| - When I first graduated college I didn't have a working
| vehicle but got a job miles from the house. I would leave
| around 3am and walk for 5 hours to be there at 8am, then
| hitch a ride home. I did this until I could afford a
| bicycle, which I had for about a month before someone stole
| and I was back to walking.
|
| - I know a woman who recently (w/i the last 2-3 years) was
| talking about how when her vehicle broke down one night she
| ended up having to walk 12 miles back into town.
|
| For poor people there's this hard wall where if you stop
| it's akin to laying down and dying, the results are
| catastrophic. So you do what you must. People who are not
| poor often don't understand how it is that someone can't or
| won't take the time to talk to a therapist about trauma.
| They can't afford it either in time or money.
| belval wrote:
| I wonder where you live for that to be true, in my experience
| everyone just complains all the time about the previous guys'
| craftsmanship and that's especially true in trade and
| engineering.
|
| > restaurants
|
| KitchenConfidential is a subreddit dedicated to complaining
| about shitty customers.
|
| > construction
|
| If you don't hang out with construction worker, you can find
| almost any YouTube video that goes over some aspect of
| homebuilding, scroll down and see comments with "As a carpenter
| of 15 years that guy is a moron for X and Y".
|
| > teaching
|
| I don't have public examples of that one but a lot of my
| friends are teacher and they are an absolute blast to be around
| because they keep complaining about stupid helicopter parents,
| overbearing principals and other bad encounters. No idea what
| kind of teacher you hang out with. Same goes for doctor and
| nurses btw, put two of them together in a room and they will
| start complaining about patient X and Y.
|
| > IT Support
|
| There are 4-5 subreddits like TalesFromTechSupport that are
| literally only stories from IT technicians.
|
| All of the above to say, really happy for you if Software
| Engineers are the ones that complain the most.
| yoyohello13 wrote:
| You're right, my post is hyperbole.
|
| However, creating a blog for your complaints seems unique to
| software developers, lol.
| klardotsh wrote:
| Outside of SEO, marketing, and other sales-adjacent
| purposes, software developers are some of the only people
| with indie blogs anymore, which I think explains this. The
| practical difference between posting on my blog about ugly
| code and posting on a subreddit/forum about ugly code is
| primarily who owns the data and where it is stored. The
| restaurant workers are still doing a similar type of
| venting.
| madeofpalk wrote:
| I don't think it's _that_ unique, it 's just that creating
| your own website (even if it's a hosted blog of medium or
| whatever) is not really something most people do.
|
| _Plenty_ of people complain about their job on reddit or
| twitter or tiktok or whatever. Internet is full of it.
| manicennui wrote:
| I complain because the impact I can have on people's lives now
| is far greater than when I was working fast food or picking
| orders in a warehouse, but the people I work with either don't
| give a shit or are incompetent. Then we wonder why dealing with
| various companies is so irritating and they create so many
| problems in our lives.
| throw555chip wrote:
| In the Navy if people weren't complaining, we knew something
| was wrong.
| switchbak wrote:
| Almost every teacher I've known has complained a lot more than
| most of the S/W engineer folks I know. I do complain a bit
| myself though, but I think that's a reflection of having high
| standards and an eagerness to improve things (to put a positive
| spin on it).
|
| You do make a good point though - we don't have to work in the
| sleet, or in human filth in a 2 foot crawlspace filled with
| spiders. It could be a lot worse!
| jiggawatts wrote:
| One unique aspect of software engineering is that it is still
| growing exponentially, doubling approximately every five years.
|
| As a direct consequence of the mathematics of exponential
| growth, this means that:
|
| HALF of all software developers have LESS THAN 5 YEARS of
| experience!
|
| This results in experienced devs being simply outnumbered by
| newcomers and having to perpetually fight against the rising
| tide of beginner errors.
|
| As someone with nearly four decades of experience, I'm facing
| six such doublings (plus retirees subtracting from the
| experienced pool!), meaning that I'm outnumbered by people will
| less experience 64-to-1.
|
| In my time I've seen every wheel reinvented -- badly -- at
| least three or four times over. I've seen the same huge,
| glaring mistakes made over and over by new people. It's
| literally impossible to convince them of their mistakes because
| it's one voice against dozens.
|
| Few if any other industries are like this because they don't
| have the same insane growth curve. Surgeons with less than 5
| years of experience are hugely outnumbered by surgeons with 10,
| 15, 20, etc... years of experience all the way up to 50+. They
| don't get to _overrule_ the Chief of Surgery. They 're told to
| shut up and learn how to do things properly by people who made
| mistakes and learned from the consequences.
|
| As a random example of this effect, the entire industry is
| learning for like the third or fourth time that text-based
| formats are _not_ better, and their "ease of use" is a
| deceptive trap.
|
| JSON is just text, and is "so easy" -> gRPC, a binary wire
| format.
|
| HTTP is just text, and is "so easy" -> HTTP/3, a binary
| protocol.
|
| This kind of thing will keep happening until the exponential
| growth transitions into the flat bit of the S curve, and the
| average experience level starts climbing towards two decades.
| meiraleal wrote:
| True that! And this makes me happy. I hope all professions will
| be like that soon.
| par wrote:
| You've never worked in a pharmacy have you? :)
| carabiner wrote:
| You haven't met doctoral students then.
| croes wrote:
| Hard-to-swallow truths?
|
| I thought that's just common knowledge.
| kevinsync wrote:
| I would encourage anybody interested in a professional career (in
| anything) to zoom out and keep in mind that almost every
| profession is ultimately about providing service.
|
| You will primarily work with (and for) other human beings, inside
| your organization and outside.
|
| The measure of your success is often perceptive, coming from a
| boss, a coworker, or a client, and it may not directly correlate
| with your perception of what you may or may not have personally
| invested into the solution.
|
| Software engineering is philosophically no different than
| plumbing -- sometimes the job is designing and implementing a
| plumbing system in a new building, other times it's diagnosing
| the source of a leak and fixing it, many times it's clearing
| literal feces from a pipe. Your value is not just extracting
| those turds, it's often being calm, competent, compassionate,
| timely and communicative while doing so. It comes from
| perseverance for solving the problem to the customer's
| satisfaction. It also comes from defusing situations with angry /
| incompetent clients, disaster projects, and resolving chaotic
| situations. Your role is to help reduce friction and solve
| problems for a person or organization in need.
|
| That you're writing software is purely coincidental; it's but one
| of many deliverables you provide throughout the course of your
| career. The rest are "soft" -- insight, support, quality,
| reliability, trust, consistency, charisma, general likeability as
| a human being, etc.
|
| If you're doing this for a job, you're going to have to deal with
| a lot of people, a lot of arbitrary constraints, a lot of
| bullshit, and a lot of bureaucracy that have nothing to do with
| writing software.
|
| The same argument could be made for law, medicine, engineering,
| hospitality, cooking, fashion design, driving a taxi, street
| performing, drug dealing, sex work, you name it.
|
| That's just the reality of work! If you're more interested in
| making art, do that instead (or both at the same time), but try
| to understand that there's a marked difference, and they serve
| separate, necessary roles in life :)
| GMoromisato wrote:
| Well said. It took me an embarrassingly long time to realize
| this.
|
| Part of the problem is that many software engineers never get
| to talk to the actual users who are benefiting from their work.
| Or if they do, it is only when they complain about bugs or
| missing features.
|
| Now that I'm a consultant, talking directly with customers, I
| can see the excitement in their eyes when I solve a problem for
| them. It's usually a trivial piece of code that any junior
| engineer could do, but it solves a real problem that they've
| struggled with.
| throw555chip wrote:
| Virtual feces removal and pipe laying, that pretty much sums it
| up.
| h43k3r wrote:
| What a great comment. Thanks for writing this out.
|
| One more thing to mention here is that Software Engineers are
| paid more because the industry is able to scale well to
| individual engineers outputs.
|
| One thing where Software Engineers differ from a lot of others
| is asymmetric input and output. A single change in production
| can save millions of dollars easily. This is possible but
| difficult to do in other engineering fields like Construction,
| Hardware etc.
| mannyv wrote:
| In addition, a huge amount of the time you spend will be trying
| to figure out what the code is actually supposed to do.
| freeone3000 wrote:
| >software development is not a dream job
|
| If your worst complaints are that you have to work with others,
| that solving the problem matters more than how you do it, and you
| have to sometimes have a pointless meeting, I don't think _any_
| job will work for you. High wages, good conditions, medium social
| status, high bargaining power, and you get to do something you
| love. It is the best job available.
| btbuildem wrote:
| This reads like a person who has walked past a couple of turns in
| the road from the starting point, and is looking back to describe
| the totality of a grand journey to the his naive uninitiated
| inferiors.
|
| Kid, you're just at the beginning.
| ram_rar wrote:
| > Nobody gives a f* about your clean code
|
| There is more nuance to this. Soft engs need to realize what
| stage of product and business lifecycle they are working on. Most
| importantly, get into the mindset individual contributor not just
| a programmer [1] (highly recommend reading Patricks blog on this)
|
| 1. If you're building 0 -> 1, the focus is shipping early and
| faster. This is not the time to crib about SLOs and chaos
| testing. I'm not saying these things are not important, but very
| likely they are way down the list.
|
| 2. Once you have crossed the chasm and have a mature product or
| platform that product engineers rely on. Then reliability, fault
| tolerance SLOs etc matter a lot more. This is the phase, I'm more
| concerned about using the right abstractions and ensure tech debt
| is managed well.
|
| 3. Product is in KTLO mode - In this phase, you could probably
| spend quarters LARPing on making things better and afford to work
| on things that very likely have diminishing returns.
|
| Nobody gives an eff about your clean code, if no customers are
| using it.
|
| [1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
| pr...
| toomanyrichies wrote:
| > The user doesn't know how the codebase looks. The user just
| sees what features that product is offering. So don't get overly
| attached to your clean and elegant code. Focus on shipping the
| feature on time and bug-free.
|
| This is a slippery slope. True, the user doesn't see the code.
| But they do see the feature set (or lack thereof), and the speed
| at which you're able to update that feature set to suit your
| customers is a function of how easy the code is to change. In
| turn, that ease of changeability is a function of how easy it is
| to read, maintain, and reason about.
|
| Focusing on "shipping the feature on time and bug-free" is good,
| but at the extreme it can lead to the mentality of "I'll fix the
| tech debt later", with "later" being indeterminate. Which is when
| the old saw about tech debt being like credit card debt starts to
| bite one in the ass.
| wly_cdgr wrote:
| I love the idea of shipping a "bug-free" feature before the
| heat death of the Universe, it's beautiful to have noble ideals
| like this.
| ornornor wrote:
| Because there is no middle ground, right? It's either perfect
| code that will never ship or unmaintainable code that gets
| shit done.
|
| Besides if you let "we'll fix it later" take hold, you
| eventually end up shipping features after the heat death of
| the universe while also having unmaintainable code. The best
| of both worlds.
| winrid wrote:
| 11). Despite excitement and encouragement to learn, after 10
| years of learning, staying employed at the same salary level
| becomes harder, not easier. :)
|
| There are outliers... but I would say on average ageism hits most
| of us. Being a specialist is a must at that point (if you want
| $$$).
| omginternets wrote:
| If you're a junior dev, I'd urge you consider that there is a
| difference between software engineering and the digital factory.
| The author seems to work in the latter.
|
| IME, the people who say such things as "college won't prepare you
| for the job" or "CS doesn't matter" are invariably the ones who
| find themselves grinding away at REST endpoints and becoming
| embittered.
| kagakuninja wrote:
| College absolutely does not prepare you for any software job,
| unless you are some kind of ivory tower architect that can
| tinker in a lab with no need to ship products or work with
| other teams.
| omginternets wrote:
| Speak for yourself.
|
| There are few things more practical than a good theoretical
| grounding when your job is to:
|
| 1. design and implement a database
|
| 2. design and implement a p2p consensus protocol
|
| 3. design and implement a programming language
|
| 4. train and validate an artificial neural network
|
| 5. reason about concurrency
|
| etc.
|
| At some point, we really need to start distinguishing the
| kind of programmer who writes REST endpoints all day from the
| one who engineers the systems other programmers treat as an
| abstraction. Both are respectable jobs, but the former is
| closer to plumbing than engineering. The former is also less
| well-paid, has less job security, more on-call duty, less
| intellectual substance, less technological innovation (but
| arguably more _commercial_ innovation), more grunt-work and a
| lower barrier-to-entry.
| Tistel wrote:
| as a 20+ year developer, this is excellent. One of the bigger
| leaps for me (which the author mentions) was going from toy CS
| assignment projects where I wrote all the code and knew it inside
| and out to huge multi year projects with hundreds of developers.
| It was a giant spaghetti code of math heavy C/C++. I was always
| surprised it worked at all. You don't even know where to start to
| add some feature (don't panic!). Some highlights where comments
| above a particularly tricky function was something like: "do not
| change this, you think you understand it, but, you don't. move
| along" and something like: "In Graecia antiqua, pueri tui similes
| in extremis rupibus remanserant mori." (latin for "In ancient
| Greece, children like you were left on the edge of cliffs to
| die.")
| reactordev wrote:
| The soft skills section has some great examples of where the
| author lacks his/her own soft skills.
|
| Some folks, during stand up, just want to get on with their day.
| They will say things (Like George Did, "I helped so and so all
| day") just to keep it moving. Doesn't mean they truly believe
| what they just said, they just want to get back to work.
|
| Sometimes, people will do things, things that seem like they are
| incompetent or don't care, but really that is your own bias (Why
| did they not help me when I needed it?) and make you look like
| not the team player. Instead, you should have gone to "George"
| and said, "Hey, thanks for looking at that issue, I managed to
| solve it with Michael's help, here's how we fixed it." Lead by
| example. Lead with empathy. Maybe George spent only 5 minutes
| with you because he has deadlines and doesn't have the
| communication skills to say "Hey Bob, I'd love to help you,
| really I would, but I have this hard deadline for this feature
| I'm working on and it's stressing me out because I can't solve
| this edge case". Use your words, explain your thoughts, people
| will be WAY more receptive and will want to work with you. Again
| and again.
| cheriot wrote:
| > 10) You will profit more from good soft skills than from good
| technical skills
|
| Related to this, your customer is not the company's customer,
| it's your management chain. It took me an embarrassingly long
| time to internalize this. The stories executives and managers
| tell each other is what decides you career trajectory. What is
| their priority and how will they judge the outcome?
| jdeaton wrote:
| > your customer is not the company's customer, it's your
| management chain
|
| Another: some coworkers will have spent so long in large
| corporations that they've internalized the pathological
| dynamics of large organizations as universal truths.
| cheriot wrote:
| Your customer isn't going to decide salaries, promotions, or
| who gets laid off. Here's your universal truth: focus on the
| person whose decision affects your outcome. If you work for
| people that will see and reward your focus on the user,
| that's great, keep it up.
| justin_oaks wrote:
| > Because if you promise to deliver it by Tuesday and you run
| into some problems, you won't be able to fulfill the promise.
| Instead, if you accept Friday as a deadline, and you finish it by
| Wednesday, you can deliver it 2 days earlier.
|
| Or you can deliver it on Friday.
|
| I once had a boss that taught me an important lesson. Some other
| party (business unit or company, I can't remember) asked for some
| work to be done. He said for me to not work on it right away. I
| said I could get it done in a couple hours, so why not do it
| right away? He said it was to manage expectations and not give
| the other party everything they want right away or they'll come
| to expect it.
|
| Edit: I also wasn't to start it right away because the work may
| not get done at all. Some of it was to delay to determine whether
| the work was even necessary. And some of it was to push back to
| ensure that we're not ALWAYS giving in to every demand.
| reactordev wrote:
| If you're reading this, this is what not to do. Plan your work,
| expectations of delivery should be on those milestones of
| sprint releases or whatever yard-stick you are using for
| planning. Simply doing work as fast as it comes in is a sign
| that you have no planning. No road map. No future outlook of
| feature sets. You are flying by the seat of your pants.
|
| This isn't a lesson to learn, it's an anti-lesson. Yes, don't
| work on things right away and deliver right away as your
| "customers" will expect it, but why is that a bad thing? Why
| can't you easily deliver features when they are ready? Why is
| this boss giving you such bad advice?
| justin_oaks wrote:
| I may have oversimplified it. There were certainly other
| factors at play in the boss's mind.
|
| The other part of it was to not do extra work for the third-
| party when that work wasn't specified in the contract. If you
| do extra work every time you're asked then it'll quickly be
| abused. You don't want to seem like a contract stickler, but
| you also don't want to bend over backwards either. It's
| something to keep in mind.
| WendyTheWillow wrote:
| That's a maladaptive approach to the problem, is the point.
| You should have the communication skills to do additional
| work when you can and firmly say no when you can't. That's
| how an adult handles that situation rather than through
| deception and avoidance.
|
| Of course, there are external reasons that may make this
| more difficult, but IMO 2/3rds of the reasons people cite
| for doing things like this are solvable with proper
| communication. 1/3rd isn't, though.
| winwang wrote:
| This is conditioned on both parties having that level of
| maturity and good faith.
| WendyTheWillow wrote:
| Not necessarily; only in the worst cases would a coworker
| actively harm you for not helping them once you've
| established that you can. I've worked with fairly
| immature people who can still be guided by _my_ maturity.
|
| Of course, you're ultimately right. Some people just
| can't operate professionally, but I find those people to
| be rarer than they may initially appear. It's far more
| common to write someone off too early.
| throw555chip wrote:
| I understand their position, I recently had a chat with a
| guy in DevOps, I'd made a request I knew would take at
| most, 5 minutes. He said he'd try to get to it by the end
| of the week. That would potentially have caused my story
| to carry over to the next week.
|
| I opened a Teams chat and asked about it. He said his
| manager told them to manage expectations. He said he'd
| cut me a break since I was technical and would understand
| and got it done in 2 minutes.
| WendyTheWillow wrote:
| A classic book called The Phoenix Project talks about
| ways to manage this. If I recall correctly, teams can
| fall into a vicious cycle where they only respond to
| immediate problems and, therefore, cannot schedule and
| prioritize their work. By maintaining a work backlog that
| gets prioritized and saying no to everything else, the
| team can ensure their work capacity gets respected and
| not get flooded with more than they can handle.
|
| So, in this way, your DevOps coworker is right. However,
| I don't think it's true when a team _isn 't_ at capacity,
| which is the scenario I envisioned when I replied. In the
| case where it costs little to nothing to quickly meet
| another team's request, the mature thing, IMO, would be
| to either a) do that thing or at least b) engage in good
| faith to put the task into your work backlog and
| prioritize it based on the larger impact of the overall
| project to the company as a whole. When a team isn't at
| capacity, the work _would_ be done immediately while
| simultaneously reinforcing the value of the process to
| protect your work capacity and prioritization ability.
| Everybody wins.
|
| I suppose this is what I mean by "maturity"; teams have
| established processes to _protect_ the team, but if the
| process allows for additional work, it 's maladaptive to
| gum up the works just to keep expectations low.
|
| ...but that response is the "full PM" treatment; that's
| what I'd tell my boss or answer in an interview. In
| reality, I think of process as a "backstop" of sorts. You
| invoke process only when you're reaching some kind of
| capacity or limitation. If it's no sweat, just do it.
| reactordev wrote:
| This is the way. If you aren't at capacity then the
| manager can step in and say "yeah, we can do that, let me
| get a ticket/issue/record of it so we can track it" and
| then proceed to work on it. This works in Kanban really
| well. If you are at capacity or have planned a sprint
| already and are midway through the run, it's ok to say no
| and get it prioritized in the backlog. If you're DevOps
| and the Ops part of the role requires you to respond to
| tickets in a timely manner then this breaks down.
|
| What we are saying though is that having a plan is a good
| thing. Protecting the plan is a good thing. Adopting work
| and helping others is a good thing. The work being
| adopted needs to be planned and prioritized though. If
| it's a small task (like the OP said, it was a 5 minute
| thing) than opening a chat with them about it after
| creating the necessary record is fine. The fact they
| agreed (regardless of classification that they were
| technical so they would understand) shows there's hope in
| your org for empathy.
|
| What you shouldn't do is say no to adopting the work
| while you sit back and play wordle until you feel the
| person has waited the necessary amount of time. Also,
| don't write systems that require 14 approvals and a
| shaman and waiting 48 hours for a status change before
| you can begin work.
| batty_alex wrote:
| Not sure I agree with not starting work on it right away so you
| don't finish early but, I've learned that constantly delivering
| earlier than you say can make people not believe your estimates
| - ditto for always being late
| WendyTheWillow wrote:
| Yeah, that's... awful. The real problem isn't that you do this,
| per se, but that you're not incentivized to improve the
| business. You should _want_ to hop on this and deliver it in a
| couple of hours; it 's up to the business to make that
| something you directly benefit from.
| matheusmoreira wrote:
| > it's up to the business to make that something you directly
| benefit from
|
| They never do though. People's reward for "improving the
| business" by being efficient is more work, not more money.
| LMYahooTFY wrote:
| Agreed, but as someone doing software work for a non-tech
| company with tech-illiterate leadership, it doesn't happen.
| Which forces you to play this game, or you'll find yourself
| drowning in impossible demands because the business side
| doesn't understand why things they want to do are so often
| pivoting around their technical staff.
| snarfy wrote:
| Aka the "Scotty principle"
|
| https://tinyhydra.com/the-scotty-principle/#what-is-the-scot...
| trash_cat wrote:
| It's called expectation management.
| pyrrhotech wrote:
| Here's another good one. You almost certainly will never make it
| to the upper class with this career, no matter how well you
| perform, unless you transition to management and climb to VP+ in
| a large company or start your own company. You can be comfortable
| as an engineer, but it's not the gold mine lots of folks think it
| is.
| askafriend wrote:
| What income level would you say is upper class?
| pyrrhotech wrote:
| I would say upper class is about net worth, not income, and
| probably top 1% or so would qualify
| otalp wrote:
| Most Big Tech engineers are in the top 1% net worth for
| their age
| booleandilemma wrote:
| If you believe 3 is true, then 7 will be true.
| g9yuayon wrote:
| > College will not prepare you for the job
|
| My personal experience says that this is a misconception:
| https://www.reddit.com/r/programming/comments/267s49/comment...
|
| My college taught me essentials that carry me until this day.
| Actually, I didn't even know how to use a computer before I got
| into college, yet I was very well equipped when I graduated. What
| I was taught was harder and deeper than what I worked on when I
| started in IBM WebSphere, so getting good at my job, at least to
| a certain degree, was no big deal. Day-to-day tasks are really
| not that hard. What's really hard is solving unseen problems, for
| which the college education becomes really helpful.
|
| >> The college will prepare you for some basics, but what most of
| the colleges teach is so far away from day-to-day jobs
|
| I depends on what "basics" means. I'd argue that what we need in
| a job can be easily learned on the job, like a programming
| language, domain knowledge, CSS this or framework that. What's
| hard to learn systematically and intuitively (still possible, of
| course) are fundamentals: matrix calculus for you to understand
| the basics of deep learning; stochastic process to truly
| understand diffusion models, OS fundamentals + CPU architecture +
| parallel programming techniques to truly optimize a complex
| program, deep understanding of distributed systems to design
| modern stateful systems, deep understanding of mathematical
| statistics to come up with new ML models, programming paradiagms
| so you can learn any programming language easily, end-to-end
| understanding of how to write a compiler so that you can write a
| descent compiler or interpreter when you really need to design a
| DSL instead of thinking YAML + Jinga is the best thing in the
| world. The list can go on and on, and such fundamentals are
| really hard to learn systematically on the job.
|
| Case in point, a colleague of mine used to mention how he learned
| distributed system in his college: his professor would ask them
| to read a paper before each class, and then the professor would
| ask them deeper and deeper questions, give them historical
| context, and challenge them with all kinds of corner cases. How
| many people could get this level of drilling outside of college?
|
| Another example, in the software engineering classes that I took,
| we learned a lot of things about formal verification: temporal
| logics, infinite automata, abstract interpretation, model
| checkers based on OBDD and on SAT, and etc. So now learning TLA+
| for my work is really a delight. I couldn't imagine I would be
| able to learn all the maths behind formal verification on the
| job, as I wouldn't have access to professors and TAs for
| questions, there would be no one to distill a 500-page book into
| its essences, there would be no seminars for us to discuss
| papers, there would be no well-designed projects that came with
| professors' feedbacks, there would be no carefully chosen problem
| sets that were possible to solve yet thoroughly challenged me...
| Elucalidavah wrote:
| > You will *profit more* from good soft skills than from good
| technical skills
|
| The rest of the truths I'm more or less okay with. But this one,
| no: in large orgs, people with good "soft skills" will profit
| more *to the detriment of the projects*.
| wolfspider wrote:
| The time you spend on projects is, according to what the PM tells
| sales, two weeks for a feature and three weeks for bare minimum
| requirements new product. Outside of that your own company will
| guilt you into some feeling of inverse wage theft where you make
| up for it by donating your free time. Realistically, three months
| to build an app you can demo is tight but those are competitive
| timelines and you want to be competitive don't you? AI I'm sure
| has skewed this towards less effort to meet those timelines (I
| hope). Another hard to swallow truth is that sometimes you are
| just given a project there is no optimal solution for because you
| were meant to fail at it. Usually it's a problem client or
| impossible task. The more skilled you are the more likely it gets
| assigned to you. Developers that get to cherry-pick all of their
| assignments are also the ones that get to lie about their time
| allocations on projects (to add insult to injury). If you are a
| new hire you will be doing a lot of their work for them so
| climbing up the ladder takes a lot of humility. Most devs super
| concerned about other people's mistakes usually cause a ton of
| problems themselves and this concern is directly related to all
| the things they are actually hiding/covering up in reality. It's
| not uncommon to find that the Super Saiyan coder is actually
| keeping a proverbial building from falling down with a toothpick
| but they are very concerned about the formatting of everybody's
| code. Younger developers think, by default, everything is crap
| but they don't even bother to hide any of their screwups and they
| have the energy to keep screwing up for a long time and at an
| accelerated pace. This, ironically, does mean more money for the
| company so hiring a lot of young developers is good for the
| bottom line and makes customers seem very engaged.
| zafka wrote:
| This article restated a lot of the downsides of being a "software
| engineer", but the real highlight was the cartoon. "How many duck
| size horses are you willing to fight" LOFLMAO
| AtNightWeCode wrote:
| This biz have basically driven me insane.
|
| Some comments.
|
| The problem with time estimates is that you often have to
| estimate not what to do but a vague vision of something. We want
| it to be easier to do X. How many hours?
|
| I agree with what to promise. The problem here is that you will
| get pressured into bad decisions. Somebody might say that it's
| just a new button. It is never just a new button.
|
| The joke, junior devs work with coding, senior devs with people
| is true. Many coders quit coding after some years and go full
| time into management positions. At some companies that is
| expected and you are being looked down upon if you are "still"
| coding.
|
| Clean code does not really tell if a solution has good
| architecture. I have seen horrible solutions that use clean code
| and great solutions that have mediocre code.
|
| Management typical just want new features. Prepare to be called
| in to help resolve issues related to bugs that has been known for
| months but not been prioritized.
|
| Third-party companies are not your friends. Be prepare to work
| with people that will straight up lie about things. Also be
| prepare to work with colleagues that does the same thing.
|
| People will try to take credit for your work. Management people
| are experts in this field.
|
| But the worst thing is also the best thing about being a coder.
| You have to to keep up and learn new things. The biz is crazy
| fast. It is easy to challenge yourself. The amount of new cool
| stuff coming out is just amazing.
| robbywashere_ wrote:
| Whattaya mean, the 5 round 60 minute leet code 'technical
| questions' with 5 minutes left for any questions never prepared
| me for this!??!
| inlined wrote:
| I feel like Cal Poly SLO prepped me for "real programming"
| relatively well. The software engineering major has a year long
| capstone program building software for a real company. I built a
| scriptable GPS emulator for Trimble. I was also required to do a
| work study to use software engineering to the benefit of someone
| other than software engineers (I worked on real estate).
| l0b0 wrote:
| Sounds like some bitter lessons from some pretty bad workplaces.
| Not everywhere is this bad, people. Expect to change jobs a few
| times before you find a good fit.
___________________________________________________________________
(page generated 2023-11-08 23:01 UTC)