[HN Gopher] Things they didn't teach you about software engineering
___________________________________________________________________
Things they didn't teach you about software engineering
Author : mikecarlton
Score : 325 points
Date : 2023-01-06 22:38 UTC (1 days ago)
(HTM) web link (vadimkravcenko.com)
(TXT) w3m dump (vadimkravcenko.com)
| fullstackchris wrote:
| > You'll need to work around incompetence
|
| This one I am truly struggling with, and probably will the rest
| of my life. Sadly it hinders the success of all of us as software
| developers. I'm currently reading "How to Win Friends and
| Influence People" by Dale Carnegie and loving it, but can't help
| but thinking in the back of my mind that somehow all these rules
| and guidance he has for being a decent human with other humans
| are extremely challenging when (in some cases) you are FORCED to
| work with said incompetant collegue. I agree entirely with the
| authors wording around this point, including "frustrating",
| "exhausting", and "toxic". Call me an asshole but I'm an
| engineer, by definition I like doing things efficiently and to
| the point. Working with someone who can't be either is incredibly
| challenging. Would love to hear more strategies people have
| developed to deal with this.
|
| Reading comments here, I want to be clear: I'm not talking about
| some ego-based notion of "incompetance" like "I can write code
| better than you". I'm talking about the bigwig guy on your team
| with a big wallet who tells you the product should be implemented
| in XYZ because he read an artical about XYZ in a magazine and
| thought it was cool.
|
| > Dealing with people is hard. Dealing with uncertainty is hard.
| Dealing with uncertain people is harder. And that's what you're
| going to do as a software developer.
|
| Also this, haha. This post is gold. Nice work!
| jooz wrote:
| Reading this point I realize is the one Ive improved last year.
|
| After covid crises, many seniors left, and I find myself being
| the more senior. There a few others seniors around me, but they
| have been on the same place all their life, so Im the senior
| with most different experiences.
|
| I often propose/ask other teams to implement changes that I
| need. Is often challenging, the are contrary to change.
| Specially if it comes from somebody outside their current team.
| I follow this approach:
|
| - I try to convince them, with diplomacy. Often what I request
| is also good for them.
|
| - If they refuse some _internal_ changes I propose, I live with
| that. If that issue some day impact me, I will communicate with
| them by opening a ticket. If they dont work on the ticket, will
| be a project management problem, not an software engineer
| problem.
|
| - I limit my interactions with them through their interface
| (ex: REST API provided by their service). On this point I'm
| rigorous, because the interface is difficult to change once is
| used by everybody.
|
| In summary, if they have bad implementations or bad design, I
| try to contain inside a box. Some day a new guy will be able to
| solve those internal issues. But I trace a line on the
| interface they provide, and ask for an interface that make
| sense.
| acedTrex wrote:
| The value section is great, code is worthless unless it DOES
| something.
|
| I especially appreciate the aesthetic section as i constantly
| struggle to explain that concept to people on a line by line
| basis
| flohofwoe wrote:
| > Code is secondary. Business value is first.
|
| Eh, what a predictable and boring attitude :/
|
| This advice makes sense in a company environment, but there's so
| many other motivations to write code than just 'business value'.
|
| And from what I've seen, focusing on 'business value' alone is
| the only explanation why so much software written in company
| settings is so user-hostile nowadays.
|
| My counter-hot-take: focusing on business value makes you a worse
| programmer.
| sorokod wrote:
| Worth stating nevertheless as the article is about a software
| engineer. Not a programmer, coder or hacker.
| flohofwoe wrote:
| And that's _exactly_ my other gripe! :D
|
| Those are all the same, the best programmers in the world
| (those in the demo scene) call themselves 'coders'. Calling
| yourself a 'software engineer' reeks of elitism, no matter
| how much time you spent at university.
| goodpoint wrote:
| Not at all. Software engineering is very much a thing and
| requires a different skillset than programming.
| flohofwoe wrote:
| I suspect this may be a 'cultural' issue:
|
| For instance in Germany with its strong engineering
| tradition, nobody in their right mind would call somebody
| who builds software an 'engineer' (there are some google
| hits for "Softwareingeneur" but I bet this has a fairly
| recent thing and has been leaking back from English).
|
| A person who builds software is simply called a
| 'programmer' or 'developer' here.
|
| And I _really_ have my doubts that there 's any
| meaningful difference between what's called a 'software
| engineer' in the US and a 'programmer/developer' in
| Germany. Building software requires creativity, planning,
| experience, rationalism and problem solving abilities,
| all in the same person. If you don't have that, then
| don't call yourself a 'programmer' ;)
|
| Out of interest what are the different skillset
| requirements between 'software engineering' and
| 'programming'? Because I really can't think of any.
| hiq wrote:
| > Out of interest what are the different skillset
| requirements between 'software engineering' and
| 'programming'? Because I really can't think of any.
|
| You can look up "software engineer vs programmer".
| flohofwoe wrote:
| These all lead to articles which basically come down to
| separate 'architect vs implementer' roles, which is a
| long outdated view on how software development works.
| Existenceblinks wrote:
| This is true. "software engineering" was very terrible
| trauma back in university. It's almost nothing about
| coding, it's waterfall and a bunch of diagrams. I still
| think "software engineer" could be overloaded to mean
| something related to performance .. and architect, and
| some other things that's not related to coding style or
| even algorithm.
| grecy wrote:
| I have a bachelor of software engineering, accredited by
| the Australian institute of engineers. Many of my
| university buddies studied computer science, so I saw the
| difference in course loads and expectations then, and 17
| years later I've seen it play out long term.
|
| If I have to pin it down, I'd say my degree had a lot of
| focus on all the phases of the SDLC, while computer
| science and programming are just one phase.
|
| My course was an extra year and included mandatory
| classes on testing theory, large scale system design,
| real time systems, personal software process, and much
| more theory about the what, why and how of each phase of
| the SDLC.
|
| My computer science friends were just writing code,
| without much education on the bigger picture.
|
| So I would say a programmer is doing one piece of
| building a software system (like a bricklayer), while a
| software engineer keeps in mind and can actually perform
| all the tasks required to design, build, test, document
| and support the software (all the people required to
| build a building from conception to completion)
| sally_glance wrote:
| I've worked with multiple german companies that declared
| their programmers as engineers, "Jr/Mid/Sr Software
| Engineer" or the more focused "Frontend/Backend/Fullstack
| Software Engineer". Maybe that's more of a thing in
| agencies? But then I think SAP calls them "Software
| Engineer" as well.
| flohofwoe wrote:
| I suspect this is mainly because the whole hiring process
| has been internationalized, and 'Software Engineer' seems
| to have become the common international phrase for
| 'anybody who has the ability to author software'.
|
| 15 years ago it would have been "Softwareentwickler" or
| "Programmierer" (optionally with the requirement of a
| degree in computer science, which - funny enough - also
| isn't excplicitely called a 'science' in Germany, but
| simply 'informatics'), even though the job description
| would be exactly the same as today.
| sally_glance wrote:
| I wouldn't put too much thought into the naming,
| "informatics" in Germany is still a Bachelor/Master of
| Science and on the other hand at Stanford they have a
| "Mathematical and Computational Engineering" programme.
| sorokod wrote:
| I don't see any elitism. You may notice that some of the
| points explicitly deemphesiz coding and some don't mention
| coding at all.
|
| The way I see it, coding skills are necessary but not
| sufficient to claim the SE title.
| Existenceblinks wrote:
| eh.. in my experience those who always spent time sharpen their
| knifes barely create anything useful, even code looks mediocre
| because they only want to play so what they write against are
| likely to be some non realworld puzzle. And "But I write a
| compiler" is also that.
| flohofwoe wrote:
| There are a lot of _useful_ things that don 't have any
| business value, also in software. There is no business value
| in writing and maintaining a compiler for instance (not
| anymore at least), yet without compilers, no software with
| 'actual business value' could be created.
| mmcnl wrote:
| You're saying there is no business value, only to end with
| saying that there is business value? Very confusing.
|
| If you take something away and no one will ever notice it
| has no business value. If people do notice, it has business
| value. Very simple right?
| flohofwoe wrote:
| To me "business value" means it involves "doing
| business", which comes down to "making money". A compiler
| enables creating software that has 'business value' but
| the compiler has no 'business value' to the maintainers
| of that compiler (unless it's a commercial compiler which
| is a very rare breed nowadays).
| Existenceblinks wrote:
| I agree only if _fun_ is included. I 've seen a lot of _wow
| a cool opensource I wanted to try this, I want to play
| with_ , _I will find problems to justify using this_.
| revskill wrote:
| Not quite. You really need to write things from scratch to reduce
| repitition. Things like custom DSL, code generation,... is not
| there for you in first place.
|
| Domain understanding is just understanding, it's not related to
| HOW you do it effectively.
| invalidname wrote:
| I like this list. It's also missing "debugging". That's a skill
| that they don't emphasize in college because they can't test it
| and it's hard to teach. But there are ways to teach it and
| techniques. There are some books on the subject:
|
| https://www.amazon.com/dp/1484290410/
|
| https://www.whyprogramsfail.com/
|
| That can mitigate that a bit.
| djmips wrote:
| Debugging is always overlooked. Even in blog posts.
| yamasanama wrote:
| Most non-trivial programming homework assignments in college
| require debugging and a good school will provide guidance of
| how to do this.
|
| One thing I do in job interviews is to have the candidate debug
| an issue (that they usually caused themselves and that I let
| them purposefully run into). Quite the eye opener of how they
| approach bugs.
| invalidname wrote:
| You would need to debug but can you tell if a person just
| printed to the console or used advanced tooling?
|
| Can you tell how long they wasted on the debugging aspect?
|
| Nope. That's the problem. These are soft skills that are hard
| to teach but much harder to test.
| yamasanama wrote:
| Yes, I can tell, because in the interview situation I'm
| sitting next to them.
|
| And print statements are sometimes the superior choice.
|
| This ties into my other comment that these things can be
| heavily subjective. As long as it gets the job done, I
| prefer print statements used by somebody who uses them as a
| sharp knife to gain understanding of what's going on over
| somebody just clicking buttons in a fancy UI but has no
| clue. (And vice versa, obviously.)
| josephg wrote:
| I also find it odd that nobody is ever taught to _read_ code.
| We spend a lot of time writing code, but how many programs does
| the average CS grad _read_ by the time they graduate?
|
| Imagine going to school to learn how to write, but in the
| course nobody ever reads anyone else's work. And in fact, most
| people (including the professors) never read any books. For
| some reason, thats the status quo in software.
|
| In industry, learning to read other people's code is one of the
| most valuable skills there is. There's plenty of times I've run
| into a showstopper bug in some opensource library we depended
| on, or needed another feature that was missing. If you can't
| read code, how can you fix the problem? Hope there's another
| library out there which solves your problem better? Implement
| some complex workaround?
|
| But if you can read - well, you can just dive into your
| dependency, debug the issue there and file a PR. (And if you
| like, use a fork with the fix until its merged upstream).
| jdougan wrote:
| You might find this interesting
| https://www.dreamsongs.com/MFASoftware.html:
| orderedtree wrote:
| Why can't debugging be tested?
| gregmac wrote:
| I can think of a couple challenges. Let's say you're
| debugging "the website won't load."
|
| Often debugging is a hunch, and quickly branches. One person
| will go down the path of trying the same site from another
| PC. Another will try a different site from the same
| browser/PC. Another will try to ping the server.
|
| If you're running this live you're always going to have the
| chance where someone's hunch or first try basically pinpoints
| the problem and eliminates a dozen checks from their
| consideration. If you're looking for things like "did they
| check DNS? Did they try another site?" but they skipped that
| and immediately figured out apache wasn't running, do they
| lose points? Or do they get 100% for their lucky (and/or
| experienced) guess?
|
| If you do it on paper, the major problem is basically
| infinite branching for every step and possible result. How do
| you mark that? What's the minimum you need to do to get 100%?
| I think it's also unfair, because even as a seasoned vet I've
| been deep in troubleshooting to the point of (for example)
| greping source of nginx for a specific error message -- which
| I'd never have even thought of two steps earlier. I do t
| expect anything that complex on a school test of course, but
| the point is the result of each step is often the _only_ way
| to even think of the next.
| atoav wrote:
| Sure testing a beginner is hard here. But testing someone
| who _learned_ how to debug means testing their knowledge of
| the moving parts of the system they are debugging. And this
| can be explained by the person being tested.
|
| E.g. "I am going to ping an IP on the outside first, to see
| if ICMP message reaches the outside server. If yes I will
| check if the DNS server responds, if no we check the
| physical connection."
|
| That would be an ideal answer, judging less ideal answers
| fairly is certainly a challenge, but not impossible.
| no1lives4ever wrote:
| And what if the firewall blocks icmp? What if the dns
| server is internal to the network and is returning a
| stale ip? There are way too paths down this rabbit hole.
| gregmac wrote:
| This is exactly my point. It's even worse in a "school
| test" situation, because who knows what contrived
| scenario the instructor has invented depending on what
| their focus is (eg: DNS vs physical net vs routing vs
| apache config).
|
| Maybe there are multiple DNS servers for the zone that
| are returning different IPs, maybe one or both of them is
| even in split-zone configuration so it returns a
| different IP depending on if you're internal or external.
| Maybe the client has manual DNS configured or a hosts
| entry that's wrong.
|
| Each of these problems would have several more layers of
| troubleshooting steps and branching, and it's not even a
| complete list -- and this is only if the problem is DNS-
| centric! There's hundreds of other branches for each of
| the other problem categories.
| invalidname wrote:
| I can personally evaluate a specific persons skill. But doing
| this in a formal gradable test would be hard.
| no1lives4ever wrote:
| One of the problems with debugging is that everyone seems to
| approach it differently. With some of the approaches working
| better than others in some situations. Which is why a group
| debugging session works great when you have a tricky problem
| that is not getting solved by one person.
|
| We can definitely test for basic debugging and
| troubleshooting skills. But I havent found a way to
| consistently evaluate people who are capable of identifying
| and finding solutions to complex problems. These days a lot
| of these come down to framework level experience. With the
| proliferation of frameworks and tools used in modern apps, it
| is impossible to find someone who can solve problems
| involving all of them. So in a big team you want a variety of
| such experiences to cover a wider base.
|
| Having said that, I have been in many situations where i have
| had to join a debugging session involving technologies or
| programming languages where i have had zero prior knowledge
| and have moved things towards a solution by asking what at
| times seems like basic queries to help others come up with
| the solution.
| clintonb wrote:
| Debugging is difficult to test in a university/exam setting,
| but can be tested in an observational sense. Stripe does it
| in one of the on-site interviews.
| no1lives4ever wrote:
| I have been in enough debugging sessions to know that it is
| easy to weed out those who are bad from those who have the
| basics right. But trying to know if a candidate is good
| with advanced debugging is a futile exercise. You need to
| be in a few intense sessions with such people to know who
| are good/bad at these things.
|
| I have only been able to figure this about people after
| working with them for 6-12 months. Which is why it helps
| keep references to such people and have them on your teams
| in future ;-)
| marginalia_nu wrote:
| A compounding factor is that it's much harder to debug code
| you're not at least reasonably familiar with.
|
| Even if you can gain such intuition through looking at a
| piece of code, in a realistic scenario, more often than not
| you don't actually know in which file or method the bug is
| hiding. What you have is a code base and some externality
| that is wrong, the debugging process is essentially
| deepening your understanding of the relevant code (in
| relationship to what it should be doing) until you
| understand what is wrong.
|
| Debugging isn't being able to use a debugger or a profiler
| or syscall tracing tool or whatever, sure they help but the
| critical skill is being able to quickly and accurately
| model the behavior of a system in your head, in combination
| with a tacit understanding of where bugs tend to occur.
| josephg wrote:
| It can. I love using debugging problems as an interview
| question.
|
| Give the candidate some simple code (~200-300 lines is
| probably about right) with a handful of failing unit tests.
| Sit them down, walk them through running the test suite and
| ask them to find and fix as many bugs as they can in 30
| minutes.
|
| It pays to make the first bug trivial (like, a typo or
| something) and make the subsequent bugs increasingly subtle.
| You learn an awful lot about a candidate by watching their
| process.
|
| The hard thing with this sort of question is calibration.
| Candidates will be able to debug way less code than you think
| in 30 minutes. It helps to run the code past a few coworkers
| before giving it to candidates to figure out if its too hard
| a test.
|
| The surprising thing about this test is that it seems to be
| really highly correlated with senior engineers. Senior
| engineers often don't do as well as smart grads at coding
| problems because we often don't write that much code any
| more. But senior engineers seem to do waay better than
| juniors at debugging problems. If I could only get a
| candidate to do one programming problem, I'd get them to
| debug code. I think you get a massive amount of signal about
| whether you'd want to hire someone out of a debugging
| challenge.
| gregmac wrote:
| Debugging works extremely well during an interview because:
|
| 1. Your evaluation can be interactive: you're watching them
| step through, can stop and ask questions about their
| thought process, etc. If it's a theoretical problem (ie:
| not on a live computer) you can even re-calibrate on-the-
| fly if they're really quick (maybe a lucky guess) at
| narrowing down the issue, or just asking "what if this
| happened instead, what would you do?"
|
| 2. Grading the candidate is subjective, just like the rest
| of the interview process.
|
| The OP was talking in the context of college-style
| evaluation. I don't think you can apply either of these
| things to grading someone in a course. (1) doesn't scale,
| and (2) isn't a fair (or unbiased) way to evaluate
| students.
| sureglymop wrote:
| I find debugging hard when it comes to web development. How can
| I debug a typescript web app when 1. It will actually be in
| javascript once it's transpiled and 2. It will run in the
| browser and not in my ide. It uses some kind of live reloading
| dev server that is completely different than the production
| build.
|
| Currently I'm building something with sveltekit and i have no
| idea how to debug this except logging out messages.
| [deleted]
| flohofwoe wrote:
| If the code is running in the browser: source maps are the
| answer (there's a step-debugger in the browser's devtools
| panel). But also: Modern Javascript is (more or less) just
| Typescript with the type hints removed, so even debugging the
| output JS code is pretty straightforward.
| no1lives4ever wrote:
| When push comes to shove, go down to the most the basic of
| debugger tools. Print output to a tracing/console. I have had
| to resort to some version of temporary print statements in my
| code to get thru with debugging. And along the way have found
| many situations where those print statements or the
| logging/tracing equivalents introduced changes that altered
| the program's behavior.
|
| I remember finding a situation where output of console.log
| would not match reality when debugging using chrome's
| debugger while working on a react app in 2019. Had to resort
| to making a copy of the variables to get console.log working
| in that situation.
|
| When it comes to web deveopment, like others have said, it is
| easy to debug modern web apps with the help of source maps.
| We have been doing some version of that for a long time now.
| I remember using source maps with codeview back in the late
| 80s/early 90s.
| gernb wrote:
| I don't know what your setup is but I've had no trouble
| debugging typescript in the browser or on the server. In the
| browser I use the browser's devtools and source maps. It
| works. For the server I use VSCode's built in node debugger
| integration. Both have worked great for me.
| nunez wrote:
| personally i rely on barking (printf) no matter the
| environment. in fact, my personal unpopular opinion is that
| people rely way too much on IDEs for debugging and that
| barking can solve 95% of bugs. (race conditions are more
| difficult, of course)
| invalidname wrote:
| The first book above has a chapter of various tools in
| debugging web applications. You can use the sourcemap feature
| to debug TS.
|
| You are missing out on a lot of amazing capabilities by
| avoiding the browser debugger. Did you know you can place a
| breakpoint that will trigger on DOM mutation?
| hermanradtke wrote:
| Most languages are compiled or transpired into another
| representation.
|
| For TypeScript, source maps can help with the debugging.
|
| The live reloading dev server is just a wrapper around your
| code. You should still be able to use the browsers debugger
| to set a breakpoint at the function you want.
| zer00eyz wrote:
| One thing is missing from this list.
|
| No one ever gets promoted for removing features.
|
| Any code base that has had a few birthdays has stuff that needs
| to be removed and might not ever get removed.
| jsmeaton wrote:
| This can be a cultural thing but it needs to permeate down from
| the very top of engineering. Celebrate and promote cleanups.
| Track metrics you want to improve. Create burn down tickets
| that'll help others to incrementally improve some system.
|
| I've only seen this work in one company I've worked for and
| will carry those lessons with me.
| RomanPushkin wrote:
| This looks so bad because author mixes up "happy hacking" aka
| programming ("Programming is a craft" - Stallman) with industry-
| only experience. If you haven't had a joy of building things on
| your own, just for fun, the world looks boring (and even
| depressing), as it's described by the link.
|
| However, the whole another universe uncovers if you remove
| "industry" concept that has been illegally attached to "software
| engineering" concept by Vadim.
|
| In reality a lot of cool stuff has been built outside of corps,
| managers, offices, deadlines. The whole Internet works on Linux.
| Many successful games were built by folks who wasn't even once
| employed as software engineer. Some of them earned millions and
| billions.
| zabzonk wrote:
| i thought this was pretty good, the point on aesthetics in
| particular - how much code have i seen and thought "how could you
| have written something so ugly?"
| EdwardDiego wrote:
| At my first coding job, my CEO passed on to me his belief that
| code that looks ugly should be refactored asap, as the ugliness
| not only hides, but rather implies, bugs.
|
| He's been right quite often, as I progress through my career.
| yodsanklai wrote:
| Maybe because it's Friday night, you want to go home, there's
| one more test to fix after a long day of work and you don't
| have time to pull out the perfect design.
|
| Or the code is already ugly when you start touching it, your
| manager is assessing your performance based on features. Any
| time spend on refactoring is time you're no shipping features
| (worse, you may introduce new bugs). So you add your feature,
| making the code even uglier.
|
| Or of course, the person who wrote the code was not very
| skilled.
| nunez wrote:
| or you just need to ship something fast but never get time to
| "make it right"
|
| there isn't a lot of value in clean code beyond making it
| easier to maintain. it can be argued that clean code over
| time makes code safer by way of improved maintainability
| (which is true), but 99% of the time, customers won't buy
| software because of how clean the internals are.
|
| meaning: if a customer is willing to commit to purchasing
| your widget or your competitor's for $LOTSOFMONEY if a single
| feature is created for them, then you can bet your ass
| developers in both companies will author (be told to author)
| the shittiest version they can that works to win that
| customer.
|
| think about the last thing you bought that you REALLY needed.
| did you care that it was a generic brand that looks crappier
| but gets the job done? same thing.
|
| disclaimer: i am a huge believer in clean code and TDD.
| bjornsing wrote:
| Good write-up. But to me this reads more like "Everything I
| dislike about 'software engineering'", and this question pops up
| in my mind: isn't there some way around all this?
|
| I know this is kind of an unpopular opinion, but I think an
| important reason we end up with this kind of work environment is
| that we have no formal division of labor into separate
| professions.
|
| Compare e.g. with healthcare: I sometimes jokingly explain the
| situation to friends by saying imagine if there was only a single
| profession called "Healthcare Worker", and every hospital had to
| self organize "Hunger Games"-style. Everybody is hired as a
| "[Junior/Medior/Senior] Healthcare Worker" and then they battle
| it out to decide who gets to sit in the corner office, who gets
| to be a doctor and who gets to clean the toilets. Often it turns
| out everybody does a bit of everything, otherwise it's perceived
| as "unfair".
|
| When there is no rigid formal power structure people make up for
| it with "politics". I think that's to a large extent what's
| happening, and it's sort of consuming our lives...
| zmgsabst wrote:
| This is something I talk about with SDE teams I'm coaching:
|
| - we're like a football team
|
| - and that means it's okay we have different roles that utilize
| our unique skills
|
| - or because we need a single play caller
|
| - but that doesn't mean your role isn't important; QBs can't
| work with no linemen
|
| - and managements job is to be high level direction, staffing,
| and play calling
|
| - but they need to step back and let the people on the field do
| business
|
| - and only bad managers don't take feedback from the people on
| the field
|
| You can give the same speech about military units or
| professional kitchens; because it turns out the ways humans
| organize aren't all that varied.
|
| I just wish we could get to a paradigm of "team building"
| instead of "fungible cogs in the process chart". Both sides,
| employees and employers, would be happier.
| bjornsing wrote:
| > I just wish we could get to a paradigm of "team building"
| instead of "fungible cogs in the process chart". Both sides,
| employees and employers, would be happier.
|
| Sadly I'm not so sure about that. If you're mostly cleaning
| toilets in a hospital then you would benefit _greatly_ from
| confusion about your role, so that you can have a bit of the
| compensation and recognition of a senior physician. In fact
| when there is a wide distribution of ability a clear majority
| benefits from this confusion.
|
| I think the reason it works in football is that (almost)
| anybody can judge ability, so the confused state cannot be
| maintained for very long.
|
| But sure, with exceptional leadership that will stick their
| neck out to "give credit where credit is due" you can get
| around this. It's just very rare.
| zmgsabst wrote:
| Except that doesn't happen:
|
| "Janitor" and "physician" are different kind of cogs.
|
| What actually happens is that you don't build the depth in
| your janitorial department that trades require -- so the
| overall quality decreases.
|
| "Janitor" and "physician" are different teams: they don't
| "play the same sport".
| bjornsing wrote:
| In healthcare, yes, and everybody understands that.
|
| In software engineering, not so much. I think the OP
| illustrates that fairly well. What he's describing is a
| janitorial job, but he clearly thinks he's a physician,
| and he has written a blog post titled "What it's actually
| like to practice medicine".
| HollowMan wrote:
| After 10 years in the industry I agreee with almost every bit.
|
| Soft skills are never taught, rarely checked during interviews,
| but might well be themost important ones.
| HollowMan wrote:
| > Estimations will be asked even when you don't want to give
| them
|
| Actually this particular point reminds me of young-arrogant-me
| saying things like "I can't give you an estimate since its
| software, and everybody knows thats estimates are impossible,
| duh." to my boss.
|
| Boy was I young, and arrogant!
| randomdata wrote:
| When I was young I didn't want to give them because I thought
| they had to be accurate, and pined over being wrong, wasting
| hours trying to ensure I covered all my bases and basically
| doing the work to get there. I was quite good with accuracy,
| which helped feed my belief, but the effort to be accurate
| was monumental.
|
| Thankfully, I eventually came to realize that you can choose
| a random number. Nobody gives it another thought after you've
| answered.
| mmcnl wrote:
| I think it's literally what the word estimate means though.
| There's a reason people use the word estimate and not
| prediction. They want to know whether it's going to take 3
| days, 3 months or 3 years.
| [deleted]
| magicloop wrote:
| I've got a couple of life hacks that have seen me through things
| quite well: 1. My short term goals are: good quality sleep
| (8hrs), daily exercise (30 minute walk), proper healthy good
| meals 3 times a day. 2. Work intensely for 40 hours a week. Then
| switch off, and then have a could not care less attitude until
| you next return.
|
| Most work environments will recognise the discipline and reliable
| work ethic and will leave you alone. Some environments will
| measure you by hours-attendance and will push you out or
| criticise your work methods. These are not healthy places.
|
| Anecdote: I was learning about climbing and the instructor showed
| us a thin climbing rope chord (emergency back up). He explained
| it was plenty to carry your weight but comically thin. What might
| appear that it "would never work" sometimes can work. Hence my
| above advice to others.
| yamasanama wrote:
| Missing from this list is that lots of the mentioned concepts are
| highly subjective. There is no generally agreed-upon standard of
| what documentation is "proper". Or what "clean" code is. Or what
| "competence" looks like. Or what a "scalable architecture" is.
| Etc etc. Most of these words are bent by whomever using them to
| make a point (or to boost their ego, sadly). Two people could
| easily work side-by-side and claim about the other that that
| person is incompetent and defend this position here on HN with
| some horrible-sounding anecdotes.
| nitwit005 wrote:
| > Meetings are there to ensure that everything is going smoothly
| and on schedule.
|
| Hospitals are there to provide health care. But you'll sometimes
| hear a phrase in health that "a hospital bed built, is a bed
| filled" (https://en.m.wikipedia.org/wiki/Roemer%27s_law). Health
| organizations will push patients to get extra, often unneeded,
| treatments if they system has extra slack.
|
| Similarly, management calendars always seem to fill. It doesn't
| seem to matter what the ratio of staff to management is, or
| what's going on at the moment.
| renox wrote:
| One thing missed: there are two kinds of meetings, the one where
| nobody wrote down the points discussed==>time wasted, the rare
| one where someone wrote a resume of the meeting with clear action
| points and made sure to send the document to everyone asking for
| feedback, etc. These meetings are gold (provided the discussion
| was about concrete actions not moonshots)
| mypastself wrote:
| Some good points here. But I also have to make some objections.
|
| > You'll need to work around incompetence
|
| It's amusing that the article never suggests _you_ might be
| incompetent. No, no, it's the "other person" whose incompetence
| needs to be well-documented.
|
| > Rare work-life balance. In other professions, your work day
| ends at 18:00, and you forget about the job. Not here. You will
| most likely always be online and checking the code, even in the
| evening.
|
| I've always tended to avoid this throughout my career, and my
| bosses and coworkers have always been made aware of that.
|
| Wait. Would I be the incompetent the author is talking about?
| dinkumthinkum wrote:
| I wonder why so many HNers think that only software people that
| work or think about work after 5:00? Many doctors, lawyers,
| teachers, etc do the same. There are many car mechanics that
| get off work only to work on their cars or other peoples cars
| talk a lot about what happened at the dealership or whatever.
| It's really not that strange.
| gernb wrote:
| > Remote work can lead to isolation. Depending on the company and
| team structure, software engineers may work in solitude (not
| including video calls) for long periods, leading to a lack of
| real social interactions.
|
| Yep
|
| > Rarely you're building something you love. More often than not,
| it's tedious work that needs to be done
|
| You should switch jobs. The majority of my jobs were building
| something I love
|
| > It's hard work. You're sitting behind your computer most of the
| day.
|
| That's not hard. That's what I would do even if I didn't have a
| job.
| the_only_law wrote:
| > You should switch jobs. The majority of my jobs were building
| something I love
|
| Lmfao if they would hire me I would.
| astura wrote:
| >It's not a dream job
|
| Its a dream job for me and would be for 90%+ of my friends. I
| suspect anyone saying this has very little life experience. All
| jobs involve work (duh) but software pays very well, is in
| demand, only requires a bachelor's degree, and is very chill with
| a very good work-life balance.
|
| If you're working unpaid overtime then get another job. I've only
| worked about 3 hours unpaid overtime in my 16+ year career. I've
| willing worked paid overtime a few times, but not often.
|
| If software isn't close to a dream job then I'd like to know what
| is.
| tapanjk wrote:
| > One way I have found to be effective is to focus on being
| productive despite the other person. I try to find
| solutions/alternatives that may be more effective and don't
| require involving the ineffective person.
|
| This above line may sound arrogant because it sort of implies
| that you are the smartest of the lot. For all you know, you may
| be the incompetent one for someone else.
|
| However, this attitude (without being a pr*ck about it) can be
| very useful in navigating your way through the messy reality and
| becoming more productive in spite of it. It will prevent (or
| reduce) a lot of "you should have said this before", or "I should
| have known this before", or "you cannot change that now", or "who
| wrote this code?" moments.
| KrugerDunnings wrote:
| There is nothing wrong with this article in trying to paint a
| realistic picture of what is expected of a software engineering
| nowadays but man am I getting tired of this one sided culture of
| professional responsibility.
|
| I just don't vibe with this advice anymore, like all the same
| with me but I'm gonna call myself something else then, you can
| have it.
| edwardsdl wrote:
| Can you elaborate on what you mean by "one sided culture of
| professional responsibility"?
| KrugerDunnings wrote:
| > Highly unlikely that you will make a meaningful difference
| in the world
|
| This is an example of negative self talk, stop this, the
| reason you are broken is because you are trying to fix
| something, this just leads to more anxiety.
|
| Most self-improvement content by developers for developers
| tends to be very negative like I can't explain it really well
| but to compare it to this sketch:
| https://www.youtube.com/watch?v=85HT4Om6JT4
| HellDunkel wrote:
| I did not perceive it as a self improvement piece that much
| but you are absolutely spot on: the professional
| responsibilities are unevenly distributed.
| intelVISA wrote:
| Whoever wrote this hit the enterprise koolaid a bit too much,
| you're meant to sip not swallow.
|
| Calling SWE "working in IT" is where it lost me.
| yodsanklai wrote:
| (foreign speaker, genuinely curious) How would you phrase it?
| working in ...?
| dieselgate wrote:
| Not sure what your native language is (for Spanish speakers
| "working on", "working in", "working at" could be a
| reasonable distinctions) but think the punchline is that
| it's software "development" or "engineering" and not simply
| "IT". Although some may argue they all fall under the same
| general label as being IT (i'm not opinionated)
| eddsh1994 wrote:
| The majority of software developers are working on what is,
| essentially, IT both literally and in the business sense of
| the word.
| t8sr wrote:
| And the majority of doctors, nurses and lab technicians
| work in hospitals, yet they don't all have the same job.
|
| IT the job is nowadays mostly understood to be about
| installing printers and setting up computers. Software
| Engineer/Developer/Programmer builds software. Sysadmins
| manage servers. SREs develop and operate production
| infrastructure. Nobody knows what DevOps is.
|
| Outside of Germany and its neighbors, nobody thinks these
| four jobs are the same job.
| kennyloginz wrote:
| Honestly curious why you consider SWE not "working in IT"
| thablackbull wrote:
| Because he doesn't want the negative connotation that comes
| with it.
|
| Just like the debate about, "is it engineering"; by calling
| oneself as opposed to 'programmer', it conveys more
| prestige.
|
| As a SWE, he sees himself in the driver seat of the company
| and doesn't want to be associated with being 'back-end', 'a
| cost-center', etc.
| t8sr wrote:
| 20 years later I still cringe a bit at the term "software
| engineer", but that's a different debate. Given how much
| work nowadays is about technology, calling 30% of the
| working population "IT guys" is perhaps not super
| specific anymore, so language evolved.
|
| Nowadays, "IT" anywhere outside of Europe refers to
| basically an operational or support role. (I think Europe
| being the odd one out is an effect of most European
| business leaders still thinking computers are a fad
| that'll go away eventually.)
| naavis wrote:
| The dictionary definition of information technology (IT)
| almost exactly describes software engineering. So what is
| wrong with calling it "working in IT"?
|
| For reference, Merriam-Webster defines IT as follows:
|
| > the technology involving the development, maintenance, and
| use of computer systems, software, and networks for the
| processing and distribution of data
| t8sr wrote:
| I think the confusion is "IT" the sector and IT the job.
| Yes, computers are information technology, but saying SWEs
| work in IT is kind of like saying a pharmacist "works in
| medicine". Being "in IT" typically means you set up office
| computers.
| naavis wrote:
| > saying a pharmacist "works in medicine"
|
| Is this wrong? I mean, they do work in medicine. You can
| always be more specific if you want, but I don't see
| anything wrong with that statement.
|
| > Being "in IT" typically means you set up office
| computers.
|
| This is probably a thing that varies regionally. Here it
| is very common to call all the aforementioned jobs "the
| IT industry".
| surfsvammel wrote:
| Some more:
|
| The worst are when you run into code that's been around for a
| long time, but obviously doesn't work, but which have stuff built
| on top of it relying on it not to work.
|
| When two bugs manifest together in one symptom, the engineering
| approach that you have learned about breaking a problem down and
| testing one thing at a time, might not be enough to find the
| issues.
|
| All projects are chaos, learn to accept that and to navigate it.
|
| Centralising things into common classes, methods, functions,
| libraries, modules or services, for reusability, and for less
| redundancy, also increases risk, as it is now even more important
| that that stuff works.
| 8note wrote:
| Said dependencies on bugs are some of the most interesting
| things to document, because they're non-obvious, and hard to
| change
| theteapot wrote:
| > My god, how many times has my Linux machine crashed with a
| segfault? It's crazy.
|
| Zero times? It is crazy.
| selivanovp wrote:
| The last time any of my linux machines crashed with a segfault
| was in early 00's. In most cases the reason was in shitty
| drivers for some hardware.
| LtWorf wrote:
| Happened to me because of nvidia video card (unused) on a work
| machine... changed the bios to not use it and that was it.
|
| That's out of tens of machines, over several years of running
| linux.
| atoav wrote:
| Zero times here as well. And I run ~10 servers, and use Linux
| as my daily driver on my laptop.
| tossaway0 wrote:
| Even if you don't agree with everything, or the tone, there's a
| lot to be said for what is expressed in this article.
|
| To the points about time spent and business value coming first, I
| would defend them by saying first that companies of different
| sizes operate with different requirements for their staff. You
| were hired to code, but in my experience the code is only
| important when it's serving the end goal of value. It's up to you
| to make sure that you're providing value, so be fluid enough to
| know when not to say, 'not my job'.
|
| As for the grueling time expectations, I feel a lot of commenters
| are reacting to environments like those you hear about game devs;
| of course that's not alright. But yes, if there's systems that
| you work on that no one else really knows about, you'll need to
| keep tabs on them pretty much all the time. It doesn't mean you
| need to check in all the time, it means you need to write code to
| tell you on weekends when your things need to be checked out.
|
| The job I have now could probably be done by some ninja coder for
| less, but they pay me because I know how to deal with everyone
| who doesn't code while I write my code.
| Existenceblinks wrote:
| Legit lessons but deep inside I feel bad because after 10 years
| in this industry I found that no one listens to anyone, it's sort
| of a culture. One thing I don't listen to anyone is "clean code".
| When I see a job description "something something .. clean code"
| I always think "by whose authority?". Of course we shouldn't
| write a huge terrible function, but your a-lot-of-indirect-calls
| looks clean but it's not. it's 4 level deep to investigate
| something.
|
| > Domain knowledge is more important than your coding skills
|
| This is where I wholeheartedly agree with. As I'm tired of cargo
| cult, playing tools, solving puzzles for fuck sake. I pick a
| domain knowledge first when I want to learn a new language to see
| what I could write some useful (to many people) thing in it.
| Tldr; you as you go help the others, not just learning sake.
| jffhn wrote:
| >Domain knowledge is more important than your coding skills
|
| It depends. For hiring I would focus much more on coding skills
| than domain knowledge.
|
| Reminds me of a company that was getting rid of the
| expert/developper communication bottleneck/gap by having domain
| people who code, and said it was much easier to teach the domain
| to a good developper (who should end up knowing it anyway,
| possibly in more details than experts themselves, due to
| formalizing it in actually executable code (requirements often
| don't even "compile")), than to teach coding to a domain expert.
| fjfaase wrote:
| Something I would like to add to the list (being in the field for
| 33 years):
|
| Discover that your greatest struggle is with your own deep rooted
| sense of insecurity,
|
| I think that software engineering, like no other form of
| engineering, has an aspect of creativity (source code), in
| combination with many (often hidden) single points of failures
| (bugs), where cooperation with others is essential, causing all
| your insecurities to be revealed.
|
| Either you learn to hide these or they drive you on a road to
| soul searching, possibly resulting in various forms of burn-outs,
| in alienation from your family and friends outside of you work
| circle, in changing your world view and/or losing your faith. But
| which might in the end result in a form of enlightenment.
|
| I am aware that there are some other professions where this also
| is the case. Just this week, I watch an interview with the
| neurosurgeon Henry Marsh. You can watch it here (with some Dutch
| subtitels and advertisements): https://www.npostart.nl/vpro-
| wintergasten/04-01-2023/VPWON_1...
| mansoon wrote:
| Null space propagation toward. Viral outbreak of not.
| eikenberry wrote:
| > Domain knowledge is more important than your coding skills
|
| In the short run. In the long run the lack of coding skills will
| start to show and bog things down. You need both domain and
| design in equal amounts for the long term success of a project.
| fullstackchris wrote:
| Agreed. If you have a sharp grasp of most parts of the coding
| you'll need to do, the domain stuff is trivial (after reading a
| few articles and such). There is probably one small exception,
| and that is the horible esoteric world of SAP - esentially a
| bunch of made up production flows on top of more made up
| production flows, filled with alphabet soup that ultimately
| piles up to mean a whole bunch of nothing.
| nunez wrote:
| I do not at all agree with the "it's not a dream job" section.
|
| Please name another career that pays you six figures out of
| college that doesn't involve several years of additional
| education, doesn't make you wear suits, is mostly non-life-
| threatening, is constantly in demand, and doesn't require special
| accreditations or certificates.
|
| If you're spending more than your 40 working and aren't on call,
| then that is on you 90% of the time, in my experience. I have
| definitely worked more than 40 some weeks when I'm pushing
| through something, but there have been plenty of times where I
| worked less.
|
| If you can't find advancement in your current role, then that's
| also on you. Not that this matters, as finding a new job in this
| industry is insanely easy relative to other professions, and
| they'll usually pay more for your skills.
|
| IMO, you should ALWAYS be thinking about what you need to do to
| get to the next level, if career advancement is a priority.
| Everything you do should be in service to demonstrating
| capability in performing above your station and providing
| business value/revenue generation. Brag sheets and being vocal
| help a lot.
|
| I am biased; I absolutely love what I do and wouldn't trade it
| for anything.
| xyzelement wrote:
| I need to write my own post on this but the gist:
|
| 1) In the long run, benefit accrues to value generation. The
| "best developer" turning out "amazing code" that misses the
| business goal is generating zero value. It's a hard fact to
| swallow.
|
| Ideally you are someone who can both engineer good code and be at
| least a part of the brain trust that "aims" that code at value
| (solving biz problems and generating money.)
|
| That sounds obvious but most people don't even think about that.
| My rule of thumb is that unless you are _actively_ involved in
| that - ie acting as a product manager to some extent - you are
| likely under-delivering for yourself.
|
| 2) your biggest limitations are within yourself and you don't
| acknowledge them. That's the classic "I identify as X and
| therefore don't do Y" mindset, where Y is the thing that would
| "unlock" your next level. Like if you are "a C++ developer who
| isn't interested in talking to customers" then perversely,
| learning how to talk to customers (and not learning the next C++
| standard) is the thing that will let you double your comp.
|
| 3) Your attitude determines your outcomes. People who assume all
| work situations are shit (assuming that bosses are always evil,
| coworkers are always stupid, etc) end up in precisely those
| situations. If you have a more positive expectation (eg want to
| give and receive loyalty, want the company to go above and beyond
| for you and to go above and beyond for the company) you can find
| those work relationships too. (Btw that applies outside work as
| well. If you believe all women are evil you end up an incel, etc)
|
| 4) Work is a team thing, and the people matter. How you are with
| people matters too. Whether people are looking forward to or
| dread meeting with you has a huge impact on your productivity and
| therefore your career. Also, there's a Darwinian element you
| should recognize. If your team succeeds, your colleagues get
| bonuses and grow and that should matter to you, not just whether
| that happens to yourself.
|
| 5) You get paid for impact in the long run. This is related to
| point number 1. Sometimes your impact isn't code but persuasion.
| I once convinced a company to shut down a line of business and
| focus on other things. The value of that is much greater than any
| code I wrote. To make such impact you need to (a) have original
| perspective/insight and (b) convey it to people who don't have
| that insight! If you are constantly frustrated because you are
| misunderstood, you need to make a conscious effort to learn how
| to persuade people in person and in writing. And to recognize
| that it's a slow and difficult process that most people fear and
| therefore fail to go the distance.
|
| 6) The concept of work life balance is misleading and too simple
| a frame for good outcomes. The homeless guy under a bridge has a
| great work-life balance (0 work) but his life sucks. On the flip
| side, some successful people work tons of hours and have a great
| life - because they enjoy their work and they enjoy the financial
| benefits.
| mikewarot wrote:
| Once I wrote a green-field application in Turbo Pascal for MS-
| DOS, did all the field editing and screen handling, help,
| communications, and even cooperative multi-tasking. It was
| amazing knowing how everything worked.
|
| I'll never experience that again. 8(
| jmfldn wrote:
| Hard disagree with this..
|
| "Elegant code, best practices, smart solutions, design patterns
| -- these are done for the sake of your fellow software engineers
| who will work on the codebase after you rather than helping you
| fulfill the purpose of bringing value"
|
| The fact that business is about money is a truism. The other fact
| is that, good engineers care about that AND know that good
| engineering - which requires 'some' obsession with good code
| amongst other things - leads to faster iteration loops, less
| bugs, better maintenence, less incidents and SLA breaches. Do you
| know what they all equal? That's right, money.
|
| Believe me, crappy, inconsistent over-complex spaghetti code and
| poor engineering practices can really really hurt a company.
|
| As ever it's a balance of course. Every decent engineer
| understands the trade offs. For my part, I think about the
| business goals first and foremost and, to achieve those, I make
| sure my code is as simple, clear, testable etc as can be when
| realising those goals.
|
| It's often a dereliction of duty as an engineer to just get the
| job done without reasonable consideration of good practices.
| Building up tech debt? Sure, I do it all the time. But
| sacrificing what I know to be a good practice just to deliver?
| No.
| fhd2 wrote:
| "Estimations will be asked even when you don't want to give them"
|
| I think usually it's not a matter of not "wanting" to give them.
| It's a matter of not wanting to take a wild guess - which is
| talked down if it seems too high - and then be asked to finish
| the work in that time frame.
|
| Time or scope, at least one of these things needs to be flexible,
| and stay flexible until the work is done.
| jsmeaton wrote:
| Estimates are not commitments. More people need to understand
| and accept this.
|
| You're on the money about time and/or scope needing to be
| flexible. Estimates improve as you gather more information and
| complete parts of a project. Providing early feedback that
| relates to the original estimate is key!
|
| "This is more complex because of X, and will likely add Y time.
| Do we want to proceed?"
|
| Nothing worse than getting to the end of an original estimate
| and only then letting a project owner know it's going to be
| twice as long.
| philipwhiuk wrote:
| > More people need to understand and accept this.
|
| Wishing upon a star that people are better is a terrible
| plan.
| jsmeaton wrote:
| It can be taught and there has to be general agreement.
| Building trust with early feedback as scope/complexity
| changes is crucial.
|
| Wishing is indeed a terrible plan. Teams that treat
| estimates as commitments are dysfunctional. Estimates are a
| tool for budgeting in an agile-like world, and need to be
| refined as progress is made.
| quanticle wrote:
| Rare work-life balance. In other professions, your work day ends
| at 18:00, and you forget about the job. Not here. You
| will most likely always be online and checking the code,
| even in the evening.
|
| If that's the case, quit immediately. I've been in this industry
| for over a decade (oh god, has it been that long already?) and I
| have never had a job where I was "always online and checking the
| code, even in the evening". Not even when I worked at Amazon.
| Yes, I've been on-call. And yes, I've been paged, but never at
| anything like the frequency that would imply that I'm "always
| online".
| FlyingSnake wrote:
| I lead a fairly large team and I agree with this comment. It is
| certainly possible and healthier to disconnect from work after
| 17:00. Unless you're in charge of coding a nuclear reactor core
| or similar, your CRUD app can always wait. A streamlined on-
| call process should be in place instead.
|
| Taking care of your headspace and unwinding at end of the day
| should be one of the most important routines in a programmer's
| life.
| pc86 wrote:
| > _A streamlined on-call process should be in place instead._
|
| Honestly even 99% of non-nuclear reactor code doesn't need on
| call. Most of the time it can wait until the morning. Amazon?
| Sure, have on call. Your app that's used by businesses during
| the business day? Fix it tomorrow.
| quanticle wrote:
| The part of the paragraph that really bothered me wasn't
| the hours, actually. It was the implication that you would
| be expected to _code_ during those hours. Even when I 've
| been on-call, I've never expected to write code, outside of
| business hours, during my on-call shifts. Update
| configuration? Sure. Roll back a broken deployment?
| Absolutely. But if devs are writing significant amounts of
| code (beyond 10-line patches, or updates to config files)
| in order to put out operational fires, that's a big red
| flag. It means that the codebase hasn't been designed to be
| easily changed with configuration. It means that
| deployments are so difficult, it's easier to try to write a
| patch in the moment than it is to roll back and see what
| went wrong in the morning. Furthermore, any code that is
| written under that kind of pressure isn't going to be high
| quality. It's going to be code that does the minimum
| necessary, with no documentation or unit tests. It's tech-
| debt equivalent of a high-interest payday loan.
| yodsanklai wrote:
| First, there are of course many professions where you work day
| doesn't end at 18:00.
|
| As for our industry, I don't disagree with you but I'd be a bit
| more nuanced. I'm not pressured to work long hours. But I often
| feel that if I want to reach my goals, I need an occasional
| coding marathon (which I don't mind because I do like coding,
| like everybody else doing this job I suppose).
| quanticle wrote:
| Right, that's the contrast I wanted to draw. In many other
| professions it is routine and expected that you're available
| in the evenings or in your off hours to deal with urgent
| (potentially life-threatening) issues. Programming is not one
| of those. If you're routinely being called upon to actually
| work on code in the evening, that's neither normal or
| healthy.
|
| An occasional coding marathon is fine. I've done it myself,
| but I don't expect it of anyone else, and if it became a
| routine expectation (as it seems to be with the author of
| this post), I would consider it a major red flag.
| amelius wrote:
| You think that doctors never mentally bring their work home?
| Galanwe wrote:
| > If that's the case, quit immediately
|
| If you're so uninterested by your work that thinking about it
| after 6pm makes you sick, why did you pick it?
|
| I've been in the industry for 15 years, coding since 25+ years,
| and I very often think, code, read about work or work related
| things at any time of the day or weekend or vacation, because I
| find it interesting. Why would I work in something of no
| interest to me?
| jooz wrote:
| [dead]
| yamasanama wrote:
| There is a difference between "want to" and "have to". You
| are talking about the former. GP about the latter.
| quanticle wrote:
| If you're so uninterested by your work that thinking about it
| after 6pm makes you sick, why did you pick it?
|
| Doing anything continuously for long periods without rest is
| unhealthy, and leads to both declining physical and mental
| health. Working 10-12 hour days is something that you can do
| for a short burst, but if you're doing it for months on end,
| it will negatively impact you. I've been in
| the industry for 15 years, coding since 25+ years, and I very
| often think, code, read about work or work related things at
| any time of the day or weekend or vacation
|
| I think about code too, but it's rarely _work_ code. It 's
| usually about some hobby project or interesting algorithm
| that I've picked up.
| Galanwe wrote:
| I think your comment actually proves my point.
|
| You are admitting that you do think about code outside
| working hours, though you don't consider it to be work
| because.. it's code for a hobby project?
|
| That's not a valid point to me. What if your job was open
| enough that you could find dozens of interesting fun things
| to code on the side?
|
| That's the job you should be looking for.
| quanticle wrote:
| What if your job was open enough that you could find
| dozens of interesting fun things to code on the
| side?
|
| No job is that open. From your other comment in this
| thread: I have some days packed with
| meetings and calls, and I actually find it
| refreshing/relaxing to work on more down to earth matters
| in the evenings or weekend.
|
| I guess I'm fortunate in that I don't really have that
| many meetings or calls, and I don't have to spend my
| weekends and evenings doing programming. I get to do
| mostly programming during the day. Then, in my off hours,
| I have the option of programming. But I also have the
| option of doing other things, like watching TV or reading
| a book, or going for a bike ride.
| lazyasciiart wrote:
| > No job is that open
|
| Mine is.
| isityouyesitsme wrote:
| I guess with a sample size of 1, I would also be tempted
| to make sweeping generalizations on an entire industry if
| the sole same was my own experience.
| lazyasciiart wrote:
| You're clearly trying to be dismissive of someone, but
| the overly complex sentence structure makes it hard to
| tell who you are misrepresenting.
| edejong wrote:
| Because there is more to life than coding? Family,
| friendship, health, leisure... Other professionals actively
| try to separate these from their daily duties, regardless of
| whether they like their jobs.
| [deleted]
| kartoshechka wrote:
| for some people having strict working hours is a baseline to
| prevent burnout, and generally to have more diverse life
| where you have time for family, leisure, or even coding your
| pet project that you don't hate, but it doesn't put any money
| in your pocket (yet :P)
| aliqot wrote:
| Some people are dyed-in-the-wool programmers, and doing
| this is fun for us. It's eustress, not work, like lifting
| weights. Those other folks watching the clock are doing a
| job.
| watwut wrote:
| Because you are building strawman and false dichotomy. And
| also because people able to take proper rest are more
| productive in the long term.
| beebmam wrote:
| My children are being raised by a parent that cares about
| them and makes time for them. I didn't have that privilege.
| r_hoods_ghost wrote:
| Because there is a very strong negative correlation between
| overworking and productivity / quality of work. When I've
| been line managing people I find that if they work over 40-45
| hours a week their actual productivity (as opposed to their
| self perceived productivity) starts to fall off a cliff after
| a couple of weeks, so I ask people to only work their hours.
| I've sometimes had to implement technical measures to enforce
| this when someone gets too obsessive about their work(and
| have done it to myself a couple of times!). I've never had to
| fire anyone for working too much and dragging down
| productivity in a team but I've come close a couple of times.
| Galanwe wrote:
| > Because there is a very strong negative correlation
| between overworking and productivity / quality of work
|
| Working outside of business hours is not the same as
| overworking.
|
| I have some days packed with meetings and calls, and I
| actually find it refreshing/relaxing to work on more down
| to earth matters in the evenings or weekend.
|
| Sometimes I even take vacations just to code on some work-
| related projects that I find super interesting and wouldn't
| have enough focused/dedicated time on normal business days.
|
| Overall the whole hard distinction between work and non-
| work is overstated IMHO. I choose my work places because I
| genuinely like what I would do there.
|
| I will even go further: If I end up with colleagues that
| are _not_ genuinely interested in what we do to at least
| think about interesting problems in their free time, then
| it's a bozo job, I don't want to work with these people.
| Nothing great has been achieved by teams where people shut
| down their brain after 6pm.
|
| Now don't get me wrong, I understand that there are
| gruntwork places out there, where the job is writing
| braindead CRUD apps all day long, and I wouldn't want to
| think about it after-work. But then again, I wouldn't work
| there on the first place.
| quanticle wrote:
| Nothing great has been achieved by teams where people
| shut down their brain after 6pm.
|
| Why do you think that the only options are:
|
| 1. Thinking about work
|
| or
|
| 2. Shutting your brain down
|
| If I want to go hack on some Clojure after work, when the
| day job is in Python, then what's wrong with that?
| Galanwe wrote:
| > If I want to go hack on some Clojure after work, when
| the day job is in Python, then what's wrong with that?
|
| That is of course perfectly fine, but to me that
| represents a not-so-ideal fit between your interests and
| your job.
|
| Realistically, you will spend more engineering time on
| your job than on your hobby project.
|
| From my experience, that means my out-of-working-hours
| projects tend to be driven by needs or limitations I
| encounter at work.
|
| I then find it more optimal to embrace and leverage that
| relationship between during-working-hours and out-of-
| working-hours projects.
|
| This is the best of both worlds, you get work on more
| green field projects, have flexibility to choose what you
| work on, under the constraint that it solves something
| for your job, but under the assumption that your side
| projects are anyway often inspired by work, it's a fit by
| construction.
|
| Let me give you an example:
|
| Some years ago I used to manage some high performance
| computing cluster, with storage nodes attached to compute
| nodes as the jobs were very IO intensive. We used
| glusterfs, which at the time got acquired by RH and
| maintenance stopped. Me and a coworker started to dig
| into glusterfs to solve our issues. We spent months
| reading the code on our free time, reading papers on
| distributed filesystems, fixing issues in our fork
| (hoping that RH would pick up maintenance after the
| transition). That's an example of an out-of-working-hours
| project, inspired by work, that got used at work, and
| thus counts as work, while still being very interesting.
|
| This is just an example, but overall I kept that
| mentality and have been doing that kind of things for
| more than a decade. You just need to find the right job
| where you have 1) interesting problems to solve that
| inspires you to do more 2) the freedom to push your
| projects 3) the drive to work out of office hours to
| prove that your projects are worth it and push them.
|
| All the colleagues I have respect for do the same. And
| someone that does not have this spirit, for me, is not
| someone I want to work with.
| quanticle wrote:
| That is of course perfectly fine, but to me that
| represents a not-so-ideal fit between your
| interests and your job.
|
| If the day job were Clojure, I'd be hacking in Python in
| my spare time. Or some other language (Rust, Haskell,
| etc.). Or not even hacking at all, but reading a book, or
| doing something else. The entire point of having hobby
| projects for me is that they're _not_ what I 'm working
| on during the day. They're an opportunity to broaden my
| horizons. Me and a coworker started to
| dig into glusterfs to solve our issues. We spent
| months reading the code on our free time, reading
| papers on distributed filesystems, fixing issues in our
| fork (hoping that RH would pick up maintenance
| after the transition).
|
| That just sounds like a lot of unpaid overtime to me. It
| sounds like you enjoyed it, but I'd find that experience
| absolutely miserable. Working intensely on a project is
| great, but I need time where I'm thinking about something
| completely different, otherwise I burn out fast.
| atemerev wrote:
| The difference is a a single question: "do you have
| family/kids?" This is also the main reason for ageism in
| the industry, where employers prefer to hire younger
| people.
|
| I love programming, but I love my family even more.
| Galanwe wrote:
| I have a wife and a kid.
|
| Do you spend 100% of the your non-working hours with
| them?
|
| I manage to have a job, spend time with my wife, my kid,
| learn guitar, code & think on my free time, and I run 3
| times a week.
|
| I don't watch TV though ;}
| bosie wrote:
| How many hours per night do you sleep and how much per
| week do you spend on each of those listed endeavours? No
| attack, just curious
| Galanwe wrote:
| I sleep around 7h per night, sometimes 8h.
|
| I do 1 to 3 runs per week, between 45m and 1h15 each.
|
| I have a guitar teacher coming 2h/week, the rest of my
| practice is random: could be from 0 to 6h per week.
|
| Since I basically WFH 100%, I have no commute time, which
| helps a lot.
| lazyasciiart wrote:
| And that's why I only work about half the day during 9-5,
| and the other half after 6pm. Because little kids don't
| disappear from 9-5pm and I like spending time with them.
| mikrl wrote:
| You're either:
|
| - management pretending to be a wagie as a psyop
|
| - extremely privileged and never had to grit your teeth
| to pay the bills
|
| - going to have a rude awakening when the crop of younger
| millennials and Gen Z hits your workplace and you realize
| these bright young things with dreams and desires are
| only in software because it's one of the few lucrative
| careers left in this proto-fascist shithole of a dying
| civilization.
| dinkumthinkum wrote:
| This is pretty extremist. If you think this is proto-
| fascist, you must not be aware of what fascism is like.
| As far as a "shithole" or "dying" civilization, I mean
| what is an example from of civilizations that are
| tremendously better or more "living?" I would agree that
| leftist culture is pretty depressing but I GenZ is a good
| example of the kind of generation that subsequent
| generations will react against, though it takes time. As
| far as Gen Z "hitting the workplace," the kind
| programmers you're talking about don't seem to know a lot
| about computing other than React and mashing up APIs; I'm
| not sure "older" engineers that know things need to be
| that concerned.
| Starwatcher2001 wrote:
| I'm 62 and have been in this industry for 40+ years. The
| _BIGGEST_ regret in my entire life has been the time I
| spent as a young man working stupid hours on "super
| important" jobs, and missing seeing much of my kids
| growing up.
| larsonnn wrote:
| First, very funny that with each comment the author is
| older. Second, I'm 33 and regret yet. I misunderstood
| every customer is king with every customer is important
| and has the right to call me outside of work.
|
| I worked 7 years about 60-70 hours each weak for
| customers which ,,are so important" to work at weekends.
|
| No one will give you the time back you could have spend
| better by developing yourself, family time or staring
| your own carrier. But working for a company is most of
| the times lost time.
| Starwatcher2001 wrote:
| "First, very funny that with each comment the author is
| older."
|
| Yeah, not quite as quick off the mark as you youngsters
| :-).
|
| I posted a similar comment to yours in 2021:
| https://news.ycombinator.com/item?id=27065714
| arcturus17 wrote:
| > Sometimes I even take vacations just to code on some
| work-related projects that I find super interesting
|
| > what we do to at least think about interesting problems
| in their free time, then it's a bozo job
|
| > Overall the whole hard distinction between work and
| non-work is overstated IMHO
|
| Look, I continue to code and study in my free time, and I
| am still passionate about learning SoftEng and CompSci
| fundamentals, but the shit you're saying sounds super-sad
| and I definitely wouldn't want to work with someone who
| takes vacations to work on _work_ problems, either.
|
| I'll take a seasoned and passionate engineer who has a
| family (even though I don't have one!) and has to work
| around that any time of day. In the vein of what GP was
| saying, bounds on limited resources like time can produce
| very effective work habits and conversely, seeing time as
| an unbounded resource (which is a phallacy anyway) sounds
| like the recipe to have a culture of sociopaths.
| alpaca128 wrote:
| > I choose my work places because I genuinely like what I
| would do there.
|
| That's great and so do I, but I still don't see that as
| reason to work in my free time. I do some personal
| projects as well, and those are usually even more
| interesting but also more beneficial for myself. Of
| course I still think about stuff from work now and then,
| maybe I see an interesting solution when casually surfing
| the web, but I'm not going to do more about that than
| write a note for the next work day.
|
| > Nothing great has been achieved by teams where people
| shut down their brain after 6pm.
|
| Citation needed
|
| Edit: Also most teams never work on the next exceptional
| thing that will be remembered in 30 years, so why work as
| if it was?
| pjerem wrote:
| You are not describing interest, you are describing
| obsession.
|
| I love being a software engineer, still, my family is orders
| or magnitude more important than my employer's codebase. I
| really don't care about my code architecture issues at work
| when I play Legos with my son or when I ask my wife if she
| had a good day while cooking together.
|
| And I say that while currently working for a good employer on
| interesting topics.
| Galanwe wrote:
| > You are not describing interest, you are describing
| obsession.
|
| I'm describing passion.
|
| > love being a software engineer, still, my family is
| orders or magnitude more important
|
| It's not mutually exclusive...
|
| I wake up at 6am, usually because that's the time my son
| wakes up. I spend around 30m with him until my wife takes
| over.
|
| Then I work on some stuff from 6:30 to 8:30 before the rush
| of the day starts.
|
| My wife does her morning yoga starting at 8:30 so I take
| care of my son from 8:30 until the nany arrives at 9am.
|
| I do my work day WFH (with some pauses to play with my son
| or chat with my wife) until 6pm, then stop to spend time
| with my son before he goes to bed around 7pm.
|
| I cook, eat and discuss with my wife between 7pm and 9pm.
|
| We usually then head to the sofa where she watches a movie
| and I sit next to her reading/coding.
|
| She will go to bed around 10pm, I usually continue to
| work/code/read until 11pm/midnight.
|
| 3 times a week I swap the cooking part to go running for an
| hour. Or I do it at lunch time.
|
| Overall I spend quite some time with my wife and child,
| while still working between 2 and 6 hours more per day.
|
| I really don't think I have a crazy schedule, nor that I
| don't spend enough time with my wife or child, or doing
| sport.
| iojsfoi wrote:
| [flagged]
| Scea91 wrote:
| I don't see much wrong with your schedule if it suits
| you.
|
| Keep in mind that many people are passionate about
| multiple things and it is ok that they are not coding
| related. Please, just don't assume I am not passionate
| about my job if I spent "only" 8 hours a day on it on
| average. There are just more things I am passionate about
| and I have only one life to live.
| Insanity wrote:
| I think the interesting parties to answer that are your
| wife and kid (in the future). There is subjectivity in
| what constitutes "enough".
|
| And there is also quality vs quantity. Each family is
| obviously different.
|
| As friendly advice, have an open conversation with your
| wife about that. Speaking from personal experience, I
| definitely had months where I thought I was balancing my
| time well enough and my wife disagreed.
| isityouyesitsme wrote:
| Every conversation in this thread where someone implies
| what is "enough" "passion" or "accomplishment" makes me
| agree more with unionizing the industry.
|
| It's as though the absence of religion in modern life has
| left a vacuum of comradery and dogmatism, so they let
| work fill it.
| renox wrote:
| I rarely goes online in the evening but when I have an
| interesting problem, it's not rare that I have a solution when
| I wake up in the morning!
|
| So you don't really stop working at 6pm..
| spiffytech wrote:
| I typically stop thinking about work entirely after I clock
| out.
|
| I already spent most of the day on the problem, and that
| exceeds my natural interest in it.
| jooz wrote:
| [dead]
| OJFord wrote:
| It goes both ways though - if I can't stop thinking about
| something that's just not quite working yet, then I
| haven't/can't 'clock out'.
|
| I think I'd like a job with truly flexible hours: work all
| evening on something if it's occupying my thoughts anyway,
| but then get a full 'evening' to chill, full night's sleep,
| and start the next day when I'm ready. I can do the former,
| but I'm still going to be expected to dial in ~to
| pointlessly summarise it~ for stand-up in the morning. (No
| I don't have young children, yes yes this wouldn't work for
| everybody.)
| quanticle wrote:
| I'll be sure to let my boss know about your definition of
| "working" when it's time for performance reviews :)
| quadcore wrote:
| _So you don 't really stop working at 6pm.._
|
| I've started billing that. Not always, rarely in full, but I
| bill some of it. It's not just for the money but started more
| like "what exactly do I work? Best way to know is to bill
| it".
| judge2020 wrote:
| Unless you're a contractor, exempt salaried employees are
| exempt from overtime requirements and thus typically can't
| bill for overtime, unless their employer likes burning
| money for some reason.
| pjerem wrote:
| It really depends on each person. Maybe it's an ADHD symptom,
| maybe it's just me, but I stop thinking about work as soon as
| I shut down my computer.
|
| And it's not about wether I like my work or not, it's just
| that I have more important things to think about or that I
| just let my mind wander.
| red_admiral wrote:
| That might be the case in startups (one of the other articles
| on the same author's page is "Lessons learned from becoming CTO
| of a small startup"). One of the reasons why some developers
| choose to work for faceless big megacorp rather than cool
| aspirational startup is that there are megacorps where you log
| off and go home at the end of your working day, along with
| everyone else.
| roflyear wrote:
| I was trying to get my current company to cover our cell bills
| because everyone messages us all the time at all hours, even
| past midnight. When I talked to the c levels they said there's
| no expectations to reply off hours so they won't cover our
| cells because they don't want to promote that atmosphere. I
| turned off all notifications and it's much better tho I think
| people are starting to get annoyed
| bluefirebrand wrote:
| This is a part of many company's culture I hate. Where the
| "official stance" is work-life balance but the reality is
| everyone is putting in overtime all the time with emails and
| chats on their phones.
|
| When I start a new job nowadays I don't install teams or
| slack or connect my work email to my phone. If I have
| messages waiting in the morning I just address them then. If
| anyone complains, oh well.
| marginalia_nu wrote:
| It's not always the job. Sometimes it's the person. Had a
| junior developer I literally had to shoo away from his desk at
| the end of the day, otherwise he'd keep working until 9 PM.
|
| I tried to tell him: Nobody asked this of him. He didn't need
| to prove himself, it wasn't on his back if we didn't meet the
| deadline, it wasn't worth sacrificing his health and the
| relationship with his wife and more than likely burning out
| before 30.
| sunsunsunsun wrote:
| Ya this is rediculous. Ive been logging off for years at 5pm,
| sometimes even 4pm. I don't work for free. Sometimes I have had
| to work at night but that means I take a few hours off another
| day when it's slower.
|
| I often think about code at night but only in the context of a
| personal project.
| osigurdson wrote:
| >> Managers like numbers, estimates, and asking for estimates
| with an idea written on a napkin. It's just how the real world
| works -- a business has some monetary goal, but before committing
| to it, it needs to understand how much it will cost.
|
| I think everyone squirms when asked to make a prediction with too
| little information. If you want to see a developer squirm. ask
| for an estimate for how long it will take to build a given
| product or feature. If you want to see a PO squirm, ask for an
| estimate (in $) of the expected cumulative revenues for the same
| product or feature.
| kimburgess wrote:
| A lot of this stems from the accepted norm that an estimate is
| a single value. This loses a lot of information and when
| combined with other lossy estimates, this error compounds.
|
| Pair any estimate (time, cost, effort) with a confidence
| indicator. This will likely improve as more about the problem
| is known, but until then gives the ability to reason with
| appropriate certainty based on a set of inherently noisy
| priors.
|
| There's a whole set of more formal systems such as PERT (https:
| //en.m.wikipedia.org/wiki/Program_evaluation_and_revie...)
| which base off this principle. That doesn't work for every
| project, but there's often an over correction in 'modern'
| software teams where significant research, experience, and
| process that has been designed to avoid project chaos is
| completely ignored for the sake of being 'lean'.
| valenterry wrote:
| Exactly. As a minimum, it should be something like "90%
| chance it will be between 3 and 10 weeks, 50% chance it will
| be between 5 and 6 weeks".
|
| Optimally we have a probability distribution.
|
| Not to forget that over time the confidence will grow and
| estimates become more precise.
| kqr wrote:
| A single value isn't the problem -- the lack of an indication
| of confidence is. If I say "there's a 90 % chance it's done
| before March 13." that's a useful and verifiable estimation,
| even though it's only one number.
| brazzy wrote:
| It's two numbers.
| osigurdson wrote:
| >> A lot of this stems from the accepted norm that an
| estimate is a single value.
|
| If we want to estimate accurately, it is necessary to break
| work down into smaller pieces. However, we can only estimate
| the items that we can identify at the time of estimation
| (I.e., we know that we need to do A,B and C but discover that
| D,E and F are needed as well).
|
| The other factor is combinatorial explosion: we'll do A,B or
| C and this impacts what we do next. This graph can become
| enormous when attempting to construct up-front.
|
| I agree that having a probability distribution for each
| estimate is better than a single value. If you have two
| values, this is a uniform distribution. It is also possible
| to do a normal distribution, triangular, truncated normal,
| etc. However, it isn't clear to me that increased
| sophistication leads to better outcomes.
| kqr wrote:
| Ironically, the question for the PO is the better question.
|
| Product/feature value usually spans a larger range of values
| than time to build it, so you don't need to estimate value as
| accurately for it to be a useful guide. It's also often easier
| to estimate because you wouldn't consider building it unless
| you have potential customers lined up.
|
| And then if the PO says "building this feature would earn us
| back 2 developer-months in the first year alone" it's usually
| very easy for a developer to judge if building it fits into
| that profit window or not.
|
| ----
|
| Of course, nobody does this in practise because people suck at
| decision-making. The next time someone asks you "how much will
| it cost?" try asking them "how much is it worth our
| organisation? What are we willing to pay?" and it will be clear
| they have done zero analysis on cost/benefit.
|
| People don't know how to analyse -- or are uncomfortable with
| analysing -- these things so they are looking to be guided by
| their emotional response to information.
| rawoke083600 wrote:
| Good list ! The one thing I would add or emphasise: Is
| _communication skills_
|
| I WISHED in addition to Calculus and CS that some form of
| "effective communication course" was required up to 3rd year !
| Even the "basics" like how to "Respond Vs React (the emotion)"
|
| If you are a coder 90% of the time it's going to be a "social" or
| "team" activity. And where you find people you find people
| problems, egos, miscommunications, anger etc !
|
| The amount of time you will have the debate about "how to code
| something the 'correct' way" will be the cornerstone of your
| success in a team. That 'debate' about the 'correct way' is hard
| since CS is such a young "engineering discipline" compared to say
| how to build a bridge.
|
| I can tell you this, the other coders I worked by far the best
| with are the coders that can communicate or that I feel 'safe
| enough/trust enough' to talk honestly and openly and separating
| yourself from your code ("you-are-not-your-code") becomes
| automatic with these types of pro-communication programmers.
|
| TL;DR: If you want to be an effective or standout coder: Focus
| HEAVILY on your communication skill.
| rco8786 wrote:
| Pretty decent article (don't agree with everything, but for the
| most part)
|
| > Code is secondary. Business value is first.
|
| I wish I could shout this from a mountaintop. If there's one
| thing I could change about engineering culture it would be this.
| But then again I would lose my edge if everyone understood this,
| so maybe it's best that they don't
|
| Engineers: If you want to stand out in your career - take this to
| heart. Code is not the goal. Money is the goal, code is a tool to
| get the money. You work in a capitalistic business, whether you
| like it or not. Push your colleagues to build the thing that
| makes the business the most money, not the thing that is the
| "best" engineering solution. You will get _tons_ of pushback on
| this - but eventually your pushing will bubble up to someone who
| works in "the business" (directors, executives, etc) and not
| just other engineers and they will invariably support you. This
| is your contrarian view now. This is your answer to Peter Thiel's
| question "What important truth do very few people agree with you
| on?". And you will thank me in 10 years.
| IshKebab wrote:
| Depending on what you mean by "code" I disagree.
|
| It sounds like you're arguing for "just get it done quickly" vs
| "take your time and do it right". That isn't a "code vs money"
| debate it's _short term_ vs _long term_ productivity.
|
| Technical debt is a real thing. As is "decision debt" (not sure
| the official term; I mean where you make the wrong long-term
| choice because you didn't spend enough time on research /
| prototypes. For example:
|
| * Using Python because it lets you get something working fast.
| Oops three years later you're locking into Python and your app
| is slow as hell. You now spend all your time profiling instead
| of adding features.
|
| * Producing documentation and commenting code. Don't need it
| now. 10 years later everyone that worked on the code has left,
| nobody can understand it and you have to start from scratch.
|
| * Investing in tooling.
|
| * Using Bazel. It's so complicated! We'll just use Make. 5
| years later a CI run uses 300 compute hours and 6 wall hours,
| even for fixing a typo in the docs (these numbers are not made
| up).
|
| Does those things produces no business value _in the short
| term_. But it definitely does _in the long term_.
|
| Maybe that's not what you meant.
| acdha wrote:
| > Using Python because it lets you get something working
| fast. Oops three years later you're locking into Python and
| your app is slow as hell. You now spend all your time
| profiling instead of adding features.
|
| Or your app continues to be perfectly usable like almost all
| Python apps because you're not doing something CPU-bound in
| unoptimized code, and you're not seeing YouTube/Instagram-
| level growth.
|
| Performance is a real consideration but the better way to
| approach it is to make sure you understand the bottlenecks in
| your architecture and have a reasonable plan for replacing
| code when you need to. I've seen more failed apps in fast
| languages because the developers took so much longer to build
| things that they never found what users wanted or the
| performance problems they actually had weren't what they
| expected so their Go code being 10% faster mattered less than
| taking months longer to reach feature parity.
|
| There are situations where performance is critical on day
| one, of course, so part of your value as a senior engineer
| should be recognizing which situation you're in and balancing
| those needs with your staffing levels, too. Your Bazel/make
| example is similar: if you're seeing that kind of performance
| hit either something's gone badly astray or you have grown to
| the point where you can afford to have someone dedicated to
| setting up more advanced tooling because they're supporting
| hundreds of developers.
| IshKebab wrote:
| > Or your app continues to be perfectly usable like almost
| all Python apps because you're not doing something CPU-
| bound in unoptimized code, and you're not seeing
| YouTube/Instagram-level growth.
|
| Honestly I have yet to use a significant (like >10k line)
| Python app that _wasn 't_ really slow. It definitely
| doesn't require YouTube scale.
|
| "Just optimise the bottlenecks" is generally a myth in my
| experience. _Most_ programs are _all_ bottleneck.
| jrs235 wrote:
| And sadly those aren't problems or concerns for many/most
| folks. It's only an issue for those that haven't moved on
| after 2-5 years. Sad but true. Short term thinking is our
| present reality and way of conducting "business".
| Kamq wrote:
| > it's short term vs long term productivity
|
| You should pick short term. Pretty much every time. The
| tradeoffs just don't make sense the other way.
|
| There's a 9/10 chance the thing you're working on will fail
| or not achieve any sort of scale. Opting for short term
| productivity will let you find this out faster, and save you
| millions of dollars and years of time over your career.
|
| When you hit that 1/10 product, you will experience some
| pain. But you now have enough information to justify dumping
| the resources (including political capital) into a proper
| long term solution.
| bob1029 wrote:
| > When you hit that 1/10 product, you will experience some
| pain.
|
| There is a neat little trick I learned. Wait until
| leadership is under fire from customers and/or investors
| regarding the thing you thought might become an issue, and
| _then_ present your solutions. Once you have _proper_ buy-
| in, you can likely move way faster than by trying to
| constantly side-channel things through existing processes.
|
| Spinning hypothetical tales of doom in order to be granted
| permission to build something shiny is probably the #1
| thing that slowed me down in my career.
| Kamq wrote:
| > Once you have proper buy-in, you can likely move way
| faster than by trying to constantly side-channel things
| through existing processes.
|
| I've noticed this as well. It's amazing how many road
| blocks an executive trying to save their reputation can
| clear for you.
| bob1029 wrote:
| > It's amazing how many road blocks an executive trying
| to save their reputation can clear for you.
|
| Precisely. The grandmaster software engineer learns to
| manipulate organizational inertia, fear and egos in order
| to achieve their goals. Simply detecting when someone has
| their heels dug in on something will take you about 80%
| of the way there.
|
| Showing up to the 5 alarm fire with a perfect solution
| that can be deployed within 48 hours will make you look
| infinitely better than if you engage a months-long
| headbutt session with your managers about potential
| fires. Prepare your magic in secret and reserve your
| hope. If you are right, it will pay out. Be patient.
| rco8786 wrote:
| > It sounds like you're arguing for "just get it done
| quickly" vs "take your time and do it right". That isn't a
| "code vs money" debate it's short term vs long term
| productivity.
|
| I'm not. I didn't say anything about speed. I am talking
| about deciding _what_ to build. All of your examples lack the
| context of what is the best at making money for the business.
| You can 't properly make a decision about addressing _any_ of
| those things without considering the bottom line effect.
| Fixing performance for the sake of speed is not the right
| decision, unless your users are leaving because of speed and
| causing dollars to be lost. Technical debt is everywhere,
| prioritize fixing the debt that is causing monetary harm,
| ignore the rest of it.
|
| "build the thing that makes the business the most money" is
| exactly what I said. And yes there's obviously plenty of
| nuance to that, especially when it goes "meta" and you get
| into tooling and platforms and tech debt and whatnot. But as
| a guiding principle it is inarguably advantageous and
| surprisingly rarely held (in my experience).
| dceddia wrote:
| My mind jumps to things like..
|
| - Don't rewrite the architecture with microservices when
| the monolith is working fine
|
| - Avoid rebuilding the company blog on the latest CMS
| unless there are good business (time/money) reasons to do
| so.
|
| - Choose boring technology, which would be the ones that
| most of the people on the team already know, and probably
| not the cool new language you heard about last week. Avoid
| fragmenting the tech stack to keep things operationally
| simple.
|
| This is just a guess though - if you have some examples
| from your own experience it would be great to hear about
| some!
| IshKebab wrote:
| Can't disagree with any of those really. I guess it's
| really hard to draw out general conclusions about these
| sort of things when the specifics really make a
| difference. You can pretty much say "spend your time
| wisely" which is not very actionable.
|
| For instance on your last point - I've heard that used to
| argue against any new technology _even if it solves real
| problems_. Rust, Bazel, React, Typescript, etc.
|
| I would go so far as to say some of these general
| principles can be harmful because they are mostly used as
| a lazy way to defend bad decisions. E.g. "premature
| optimisation" is more often used to justify _ignoring
| performance entirely_ than it is to stop people writing
| things in assembly or whatever.
| bluefirebrand wrote:
| Premature optimization is much more useful as a deterrent
| for stuff like building complex data structures and
| processes to speed up looping through like 100 items.
|
| "But it might be a million items later!"
|
| Yeah, or the company might pivot before we ever go live
| with this feature. Just slap a for-loop in there and get
| on with your day.
| fatneckbeard wrote:
| money is not the goal. providing a useful and valuable product
| or service to customers is the goal.
| AnIdiotOnTheNet wrote:
| That's how it _should_ be, but our society has embraced the
| sociopathic interpretation instead.
| ricardobeat wrote:
| I'll have to disagree with this one, that's what that point
| is about. Great things can be achieved by focusing on UX and
| providing real value, but these are means to an end, and the
| business' end goal is still making money. Most of the time
| [1].
|
| Can you whip up a quick & dirty feature that might generate
| more revenue if released tomorrow? You can bet it will be
| done. At this moment the engineers who know when/where to
| compromise stand out.
|
| [1] companies with a strong ethos or social mission do exist.
| If you find one that makes you happy, hold onto it :)
| rco8786 wrote:
| Totally incorrect, at least in a business context. If it were
| the case, you would build that useful and valuable product
| and then give it to your customer for free. But you would
| never, ever, do that (unless it was specifically as a loss
| leader for other products) because making money is the goal.
| croes wrote:
| Business context is not the whole reality, only a part of
| it and it's losing it's purpose.
| dinkumthinkum wrote:
| That's not true because giving it away would mean you
| wouldn't be able to produce the product.
| LtWorf wrote:
| The successful startups hardly ever do that.
| jasondigitized wrote:
| Only if the problem is pervasive and people are paying money
| for it. Providing value just increases the probability that
| you will make money. You can have a very valuable
| service/product and fail miserably because you have no idea
| how to run a business and lack the know how and fuel to power
| awareness activities like marketing and sales.
| sirsinsalot wrote:
| The only reason anyone can and does make a valuable product
| or service is for some wealth. If not money, kudos, power,
| ...
|
| I don't buy the altruistic motives.
| zug_zug wrote:
| There is so much packed into the phrase "the goal."
|
| - Is it the business owner's goal? Depends on the business
| owner.
|
| - Would the CEO have a better company if they focused on
| building something great rather than extracting money?
| Depends on the industry (the premise of capitalism is yes,
| but unfair markets are a thing)
|
| - Is it (betterment of society through engineering) a valid
| personal goal to have on a strictly moral or ethical level,
| with no need of evidence or efficacy? Sure, absolutely
|
| - Are people who focus on "extracting money" sheisty MBA
| types who lie through their teeth and exaggerate every number
| and kill the company in the process of trying to self-promote
| any random thing they can control? Sounds like a leading
| question...
|
| These are all worthy distinctions imo.
| xyzzy4747 wrote:
| This is incorrect. Without money you won't get salaries. And
| people will need to find another job (at a place that does
| value money).
| croes wrote:
| Money is just the middleman pretending to be the boss.
| CM30 wrote:
| You can probably also extrapolate this advice to most jobs that
| involve building or manufacturing something. The way you make
| it, the techniques you use, the practices you put into play...
| are all secondary to whether what you're building actually
| serves a purpose/fills a need.
|
| And that's equally true of everything from programming to
| design to writing. The value of a newspaper article is often
| the story it tells, not the actual way it was written. Same
| with a video, film, tv show, design, or whatever else. Most
| people don't care how good your technique is or how elegantly
| the product was made, they care about whether it does something
| they care about.
| whateveracct wrote:
| > If you want to stand out in your career - take this to heart.
| Code is not the goal. Money is the goal, code is a tool to get
| the money. You work in a capitalistic business, whether you
| like it or not.
|
| On the flipside, you can be like me and be "meh" about business
| value (or at least, not a maximalist about it) and treat code
| as the point and fun/art/etc (easy to do with an FP language,
| for example). You'll still deliver value and even squeak in
| some fancy code that isn't the best business value.
|
| The result? Over the years, your employer(s) effectively
| subsidize your code-for-fun's-sake using the money they make
| from business value others focus so much on :)
| galangalalgol wrote:
| I had a boss for a while that took the opposite view. He just
| wanted to do interesting work. He was good at politics so he
| did, but the level he would have risen to in management if he
| had focused on business goals and money instead of fun work
| would have been much greater. But he also wouldn't have still
| been doing daily technical work which is all he wanted. We
| acknowledge that fun work can be part of total compensation, so
| accepting lower career advancement in return for more of that
| compensation doesn't strike me as unusual or a problem.
| rco8786 wrote:
| Yea no issues with that at all. That's why I prefaced my
| entire comment with "If you want to stand out in your
| career".
| bob1029 wrote:
| I learned this at some point while working in manufacturing. No
| one responsible for how much you get paid really cares how
| clever your idea is unless it makes the company more money.
|
| For me, the game theory gets pretty advanced at this level.
|
| My strategy now relies on enriching myself via equity and
| careful product decisions so that I can then go start my own
| software studio and do things my way. Presumably, this is what
| our leadership wanted all along.
|
| Trying to get my rush experimenting with new ideas under the
| current employer is really only shooting myself in the foot
| with regard to this long term plan. Any experimentation is
| reserved for side projects and weekends. At this point, I only
| bring "code" ideas to the team if I think they will
| legitimately improve the business in some eventual way that a
| non-wizard can understand.
| bitexploder wrote:
| The irony is, I started and sold a consulting business. We
| got to do some things our way, but we still had to make
| money. Overall, I say do it, but I made choices I never
| imagined I would have to make. So it goes.
| KyeRussell wrote:
| This is really the next layer up in the 'galaxy brain meme'
| of this thread. The understanding that the people that
| dissuade you from gold plated engineering solutions are not
| some inherently different monsters. Rather, they're doing
| at least roughly what you'd do in the same situation.
| bitexploder wrote:
| It's the central tension we always had. Can you do enough
| your way, and as you grow, your teams way while still
| making money. Hackers have an ethos and working for big
| corporate behemoths often means compromising that ethos.
| I feel we did, and still do, a good job. You can get rid
| of so much red tape, focus on quality, have a really fun
| culture etc. and if you hire pragmatic folks who accept
| they get all of that in return for doing the make money
| part of consulting it can be a ton of fun and very
| rewarding. But the owners and managers in the business
| are always balancing it.
| badpun wrote:
| This works in non-dysfunctional organizations only. In
| dysfunctional ones, the inmates are running the asylum and you
| will be scoffed at if your code doesn't follow the latest
| trends and buzzwords (e.g. functional programming). Nobody
| represents the business value - the product owner cares only
| about features being delivered and doesn't care (or, usually,
| understand) how the engineers do it, and the engineers are busy
| outnerding each other with "cool" tech. If you'll propose
| simple solutions using old and reliable tech, the team will
| think you're a lazy moron.
| nunez wrote:
| Agreed. There is a ton of resume/leetcode-driven-development
| out there.
| lr4444lr wrote:
| But if I don't build it with Rust with pure functional
| programming, how could I scale type correct, shared-nothing
| architecture? Who cares if customers like it? It could be a
| disaster if Coq cannot verify its correctness! ;-)
| bradlys wrote:
| I disagree with both.
|
| Code and business value are worthless. Boss approval is
| literally everything.
|
| It really doesn't matter if your ideas make a ton of business
| sense if they are in conflict with your direct manager or any
| part in the chain of hierarchy. As long as they don't like what
| you're saying - you're literally worse than worthless. Often
| this is because your idea isn't their idea - therefore damage
| to ego. Damage to ego means get that guy out of here and make
| sure I don't hear more from them.
|
| People need to understand that you're hired for a job. You're a
| glorified and well compensated code monkey. Even at $1m/yr -
| still a god damn code monkey. You jump when they say jump.
|
| I've yet to meet any hierarchy chains that are truly open
| minded to a low level IC saying anything that counters them.
| I've worked at quite a few places too and talked to a lot of
| folks about this.
|
| You'll thank me in ten years because you'll become a bootlicker
| and actually make progress in your career rather than being
| stuck in senior/staff until you burnout from the industry.
| tester457 wrote:
| This is the real answer. Ego is greater than business, money,
| and code.
| tehjoker wrote:
| ahh and finally we get the real answer that careerism is
| about playing jester to the court of the mad king regardless
| of any other concerns
|
| if you don't want to be a jester and you want satisfaction
| doing a good job professionally you need a union
| ro_sharp wrote:
| > You jump when they say jump
|
| Thankfully sometimes 'they' are the customers paying real
| money for a product or service that's valuable to them.
|
| But as you say, larger organizations have more room for
| political distractions on the way to giving that customer
| what they want.
| nunez wrote:
| Ironically, demonstrating business value is exactly how you can
| get justification to build your own things from scratch!
| roncesvalles wrote:
| Unless you're in a <10 headcount everyone-does-everything
| startup, by the time work reaches software engineering it's
| already been determined as having good business value. It's
| rarely a software engineer's job to challenge that
| determination unless new information emerges that wasn't
| factored into the original decision.
|
| Also, maybe my perspective is skewed from only ever working at
| gigantic companies but what usually grows a career is making
| your manager's life easy - becoming someone who reliably gets
| shit done on time and without drama.
| tj-teej wrote:
| I don't think this is the case.
|
| I think most engineering teams will have a "backlog" of tech
| debt. Some are things they want to do (the original
| implementation is icky but could be lived with for years
| until requirements change) and some will save the team hours
| per week in distractions/maintenance.
|
| Being able to evaluate the actual impact of the "tech debt
| clean-up" and pick the one which helps the business will
| absolutely set you apart from your peers.
| simon--poole wrote:
| I think you massively underestimate the number of startups
| with product engineers. It's becoming a much more popular
| approach with many high-performing startups, even up to the
| 250+ headcount tiers.
| wankle wrote:
| "What important truth do very few people agree with you on?"
|
| For me it's that Apache is the best web and proxy server, Java
| is the best programming language and platform, Eclipse is the
| best IDE and never use anything made formerly or currently by
| Russians including nginx and JetBrains' stuff.
| as1992 wrote:
| I mean irrespective of Apache/Java/Eclipse, saying to never
| use something made by someone just because it was developed
| by a company/people of a certain nationality is just silly.
| croes wrote:
| >Money is the goal, code is a tool to get the money. You work
| in a capitalistic business, whether you like it or not. Pu
|
| Capitalism and money are actually only the means to an end, to
| achieve the best possible for society. But as is so often the
| case, at some point the means becomes the end.
| sirsinsalot wrote:
| As if capitalism in practice has ever been about the best
| outcome society wide.
|
| It's about a means of allowing wealth disparity while the
| have-not masses are too distracted to get out the guillotine
| croes wrote:
| You are still confusing the means with the end.
|
| It is not about what capitalism is about, it's about why
| society chose capitalism instead of other forms of economy.
|
| That's why capitalism needs laws to tame it's worst
| excesses.
| cam0 wrote:
| I had never seen that cartoon about the "dream job" before, but
| it's something I've thought about so many times as I've listened
| to people talk about their dream job or dream employer. It always
| struck me as strange to dream of labor / dream of being an
| employee - must be a cultural thing.
| randomdata wrote:
| There is value in dreaming about your options.
|
| A dream house is another example of this. Let's face, housing
| is awful. The pie in the sky dream would dream of not needing
| housing at all, but more realistically I can also dream of a
| house that makes some things slightly less awful. Dreaming
| about that house provides me with information that I need to
| move towards it.
|
| More likely it is a semantic thing. I imagine everyone does
| something like that, but may not call it dreaming.
| quanticle wrote:
| Programming is a "dream job" for me. I'm getting paid to do
| (approximately) the same stuff I would be (and am) doing on my
| own time, and I have entire departments whose job it is to
| handle the boring drudge work, like accounting, taxes, billing,
| client meetings, etc. etc. Sure, there are trade-offs. I have
| to use a language that I'm not entirely happy with,
| infrastructure choices I don't fully agree with, pre-existing
| code, and meetings that I find irrelevant, but, overall, I'm
| happy with the tradeoff.
|
| And besides, it's not as if you're free of those things as a
| freelancer.
| nunez wrote:
| the "what do you want to be when you grow up" question kids get
| asked usually involves something involving labor (unless
| astronauts, firefighters, teachers, and police work for free!)
| intelVISA wrote:
| Dream 'job' is 404 for most I'd imagine. There's always the
| hardcore grifters who try and signal otherwise I guess.
| geysersam wrote:
| On the other hand, working is what most of us spend 8 hours a
| day on. It makes sense to make the most of that time, and not
| all jobs are equally interesting/fun/rewarding.
| randomdata wrote:
| _> Meetings are there to ensure that everything is going smoothly
| and on schedule._
|
| Are they? At one time in my career you just let people know when
| something isn't going smoothly/not on schedule. A quick email (or
| equivalent) was more than sufficient to raise awareness.
|
| For various reasons I eventually fell into this meeting culture.
| I don't get it. It produces this weird state where everyone saves
| up what they have to say for the meetings to avoid an awkward
| lack of participation or "I have nothing" in the meeting, which
| results in a barrage of mostly useless information, all while the
| nuggets of gold that the meeting would benefit from regularly get
| missed because everyone is too overwhelmed by the information
| overload.
|
| And because everyone saves up what they have to say, the team
| seems more distant, which diminishes other beneficial outcomes
| that arise when everyone is regularly chatting with each other.
| The information lag also dramatically decreases the overall
| efficiency of the team, not having useful knowledge as it becomes
| available.
|
| _> You might not like it, but the information must be shared for
| the system to remain efficient._
|
| The thing is, I actually like meetings. After you've recognized
| something isn't going smoothly, calling a meeting to formulate a
| plan of attack under the narrow scope of that specific problem at
| play can often lead to really great outcomes.
|
| But I dare say that if the meeting is there simply to find out
| that there is a problem, you are doing something wrong.
| yamasanama wrote:
| > It produces this weird state where everyone saves up what
| they have to say for the meetings to avoid an awkward lack of
| participation or "I have nothing" in the meeting
|
| This is an odd meeting culture. Just remove the requirement
| that everybody has to bring up something.
|
| FWIW I've never felt like that in my teams.
| randomdata wrote:
| I'm not sure it can be removed, fundamentally.
|
| After all, if everyone sent out their emails, so to speak,
| what would be left for the meeting? I mean, what are the odds
| of someone discovering something worthwhile to communicate to
| the team just seconds before the meeting starts? Any earlier
| and the email would have already been sent and there would be
| nothing left for the meeting. Maybe it happens once in a blue
| moon, but regularly across a wide number of people? No way.
|
| I've never attended a status meeting that was completely void
| of participation, so there must be withholding of information
| done so to pad the meeting. Not everyone may feel such
| pressure, but it is apparent that some - and I dare say most
| - do.
| yamasanama wrote:
| > I'm not sure it can be removed, fundamentally.
|
| I've not had this for the last 10 years, so it can
| definitely be removed.
|
| Obviously everybody is welcome to bring up whatever is
| interesting nd worth discussing, and that's what we do in
| my current and previous workplaces. But there should not be
| a _requirement_ that everybody _has_ to bring up sth, which
| would lead to the described issues..
| randomdata wrote:
| _> I 've not had this for the last 10 years, so it can
| definitely be removed._
|
| You've sat in regularly scheduled silence for the past 10
| years and people still show up?
|
| _> Obviously everybody is welcome to bring up whatever
| is interesting nd worth discussing_
|
| But logically they would have already said it when it
| first became interesting, unless they felt pressure to
| pad a scheduled meeting with content, withholding
| information from the group until the meeting takes place.
| So, again, what's the point of sitting in silence or
| purposefully denying the team information to satisfy the
| social pressure?
| yamasanama wrote:
| I don't understand what you are talking about. Obviously
| we don't sit in silence. Some things are just easier to
| discuss in a meeting than over 100 Slack messages. Those
| things we discuss in meetings.
| randomdata wrote:
| Right. Like I said in the first comment, after you know
| there is a problem, calling a meeting to discuss that
| problem can be quite fruitful. You only need 1 Slack
| message to say "Hey guys, this isn't going smoothly. Can
| we talk?"
|
| The original context was about meetings intended to let
| others know there is a problem. A time to allow you to
| say things aren't going smoothly. But why would you wait
| for a meeting to let others know there is a problem?
|
| The only reason is because you feel pressure to ensure
| the meeting isn't silence. Otherwise you would have
| logically made it known long before. What is really
| gained in withholding information from the team?
| yamasanama wrote:
| Not all issues are urgent. Most issues I encounter in my
| job are not urgent. Sometimes it's not even issues,
| perhaps just a random but interesting observation. It can
| be less distracting to the team to bring them up next
| time you have a regular team meeting scheduled, instead
| of blasting it into a slack channel or even calling a
| specific meeting. That's what sync ups are good for.
| ahtihn wrote:
| > After all, if everyone sent out their emails, so to
| speak, what would be left for the meeting?
|
| One thing I've learned is that a lot of people simply don't
| read emails.
|
| You can send out all the status emails you want, no one is
| going to read them unless it's directly related to their
| own work.
|
| Short, frequent status meetings ensure that people are
| actually aware of the status and gives them a chance of
| unblocking you if they can.
| 8n4vidtmkvmk wrote:
| this so much. we have these stupid weekly meetings where this
| one guy just asks us a dozen question. and then we try our best
| to answer them on the spot with incomplete information. just
| post that shit in the chatroom and we'll answer with a thought
| out answer when we can.
|
| standups are pointless status updates where no one listens to
| each other.
|
| even doc reviews, which can be useful, often get fucked because
| the clever folks with things to say can't leave them as
| comments on the doc so the owner had time to review and think
| about them.
|
| save meetings for things that require actual discussion, not
| questions or status updates
| GuB-42 wrote:
| As I advance in my career, I start to like the messiness of real
| life software engineering more and more.
|
| We all like starting from scratch, from a clean slate, but that's
| actually the easy part, it only becomes hard later, when the
| requirement have changed and you start to notice the consequences
| of the bad choices you made earlier, and then you try to leave,
| or restart from scratch. So you want the easy part and leave the
| hard part to others...
|
| But where is the fun in that? I went to programming because I
| like things like problem solving, and it is not problem solving
| if there is no problem. Digging into code that no one
| understands, that is not documented, working around limitations,
| finding what needs rewriting and what doesn't (with an emphasis
| on the "doesn't"), managing technical debt and deadlines without
| overworking yourself, etc... Now this is a challenge, this is
| interesting, this is the job I signed for even if I didn't
| realize at first.
|
| And don't let anyone tell you that these are not coding skills.
| These are totally coding skills, where code reading is as
| important as code writing, where you have to be able to code with
| any API, in any environment, in any style. Not just the narrow
| subset of algorithms (which is also important).
___________________________________________________________________
(page generated 2023-01-07 23:02 UTC)