[HN Gopher] Ask HN: Do you hate software engineering but love pr...
___________________________________________________________________
Ask HN: Do you hate software engineering but love programming?
I have come to a realization that I don't really enjoy Software
Engineering(& the processes that it comes with) but I do love
programming & solving problems. Finding and fixing bugs is a lot
of fun. Incidence response is a lot of fun. Hacking on new projects
is a lot of fun. Writing unit tests is fun too. Refactoring,
rewriting, sprint, agile, rearchitecting things etc aren't that
fun. I like a few languages and I am not too keen on learning new
paradigms or languages unless I have to. I'd rather get to value
now by making something that just works(and is adequately tested)
than engineer something thats future proof but takes longer to get
out. What are some good jobs for a person like this?
Author : throwwwwaway
Score : 692 points
Date : 2023-01-13 11:57 UTC (1 days ago)
| sourencho wrote:
| Not a job, but you might be interested in
| https://www.recurse.com/
| sublinear wrote:
| No
| Lapsa wrote:
| no
| strangattractor wrote:
| Unfortunately you are saying "I like doing the fun part of
| software but not the not so fun." Maybe look for a company that
| needs or uses software to enable their product but does not sell
| software or software services. Or find an area where software is
| not well established and is just beginning to be integrated into
| the business.
| armchairhacker wrote:
| You take seems to be "I like some parts of programming/SE but not
| other parts".
|
| I like:
|
| - Designing and architecting software
|
| - Writing new code (e.g. new project or feature)
|
| - Refactoring and rewriting existing code
|
| - Automation: finding new ways to do things faster and eliminate
| mechanical processes (not just new tools, but knowledge, e.g.
| learning algorithms so that when I see a need for one I just up
| an existing library or snippet instead of re-discovering it
| myself)
|
| - Using Linux and command line tools (related to automation, but
| also setting up big servers and processes is cool)
|
| I don't like:
|
| - Debugging
|
| - Writing "hacky" code (prefer to write code which should last
| long and be maintainably)
|
| - Testing
|
| - Sprint/agile and other long processes
|
| - Certain languages (e.g. JavaScript) and
|
| I really don't like:
|
| - Working on projects where the code quality is bad
|
| - Anything mechanical which can't be automated for some reason
|
| Anyways the point is that different people like working on
| different things, a decent number of people like doing most of
| the things which you hate and vice versa. So you sgould try to
| the right job and position where you can work more on the stuff
| you like, and less on the stuff you don't like. It's not software
| engineering which is the problem, it's certain parts of software
| engineering, and while you like can't entirely avoid all of those
| parts, in the right company I'm sure you can focus less on them
| and more of the parts you do like. Or, you can always try to get
| some easy job for the sake of getting paid, and do side projects
| and open-source work
| yawnxyz wrote:
| I'm very similar to you!
|
| I'm a research software engineer at a medical research
| institution in Sydney. I'm the only engineer / developer type
| person on my team, and I work with other microbiologists,
| physicians and bioinformaticians (who know scripting/programming
| but specifically for answering biological questions). The system
| I'm building tracks samples in the lab, patient data coming in
| from the hospitals, and genomics data from the sequencing lab and
| bioinformaticians.
|
| I do "engineer" type things, but I have full autonomy and I
| support the rest of the team. What we do is impactful too -- our
| clinical trial just treated three patients.
|
| I don't write unit tests because I can't be bothered. I do write
| documentation though, but for myself.
|
| Downsides are: it gets lonely being the only one that does this,
| and there's no one to bounce ideas off of; no one else knows what
| you work on or understands what you're building (which can be a
| good or a bad thing); you're that "IT person" in the back.
|
| Oh and the pay is awful compared to real tech jobs
| nchohan wrote:
| Come join us at Upmortem. We're working on an AI slack bot. We
| cut all the nonsense out. No stand-ups. No people on call. Just
| pure development. Email me at nlake44@proton.com.
| Evfank wrote:
| I googled Upmortem and the first result is for "upmortem.com -
| Blameless Post Mortems: Upmortem" but page doesn't load due to
| missing DNS entries.
|
| Don't know if this is your company, but it rhymed well with
| what you wrote here (no people on call) which I found a bit
| funny.
| xiphias2 wrote:
| Refactoring is super fun, that's the part where I learn the most:
|
| after writing many features, adding the next one gets harder and
| complicated in my head, that's when I know that the code needs to
| be much cleaner so that adding the next feature becomes easy.
|
| It often means that I delete code / completely skip a code base
| that went in the wrong direction and overcomplicated some part
| unnecesarily. And that's when my code gets much more elegant by
| achieving more and being simpler at the same time. I love it.
| [deleted]
| fexecve wrote:
| I love software engineering AND programming. But too often
| working "in software" involves neither.
| Waterluvian wrote:
| Something to be mindful of (but I'm not saying it's necessarily
| true here) is that it can sometimes be easy to re-frame the
| statement, "I like the fun parts but hate the work parts" into
| something like what you've said. Eg. "Does anyone else love
| playing hockey but hate practices?"
|
| I love solving problems and fixing bugs. I LOVE optimization
| (when appropriate). But these are like 10% of what I'm paid for
| and I appreciate it can't all be the fun stuff.
| stonemetal12 wrote:
| I have found SDET type roles to be good.
|
| At least where I have worked testing is just as process and
| meeting driven but the meeting are focused on test coverage not
| the test tool dev aspect. So I get to hack together new test
| tools in whatever way I like. The only process bit is I have to
| document how to use it well enough that someone else could run
| the test case.
| radicalbyte wrote:
| No not at all. Software Engineering is about building systems to
| the appropriate quality level.
|
| For projects I'm usually involved in: this means being
| disciplined, writing good quality tests, keeping code clean,
| documentation and following the various practises and
| conventions. This, if you're doing it properly, means you'll be
| able to ship code much faster than if just "programming".
|
| I use scrum by choice; but you can deploy a lightweight version
| that cuts a lot of the bullshit if you have a good team.
|
| If you're re-architecting things then that's a huge red flag.
| Unless the underlying assumptions have changed enormously or
| you're working for a start-up who had inept "programmers" (like
| myself 20 years ago) YOLO'd V1 then what you're doing ain't
| engineering.
| warinukraine wrote:
| It sounds like you like easy problems and don't like hard
| problems.
| cbtacy wrote:
| This is what we used to call a "code artist"
| runarberg wrote:
| Hate the industry but love the craft, is the advice I can give
| you.
|
| Programing is first and foremost a craft which just so happens to
| employ a lot of people and tends to pay pretty well. There is
| nothing wrong with keeping programing as a hobby and finding a
| different career. I personally know a couple of talented
| programmers that work in other industries.
|
| This kind of mentality is way common in some other industries.
| Woodworking and apparel jump quick to mind. I bet the number of
| talented woodworkers that don't have a woodworking career is
| pretty high.
|
| If you don't want to change careers, then there are some
| companies that value the craft more then others. In my experience
| the smaller the startup the more they value the craft (which
| unfortunately is negatively correlated with pay). Perhaps you can
| love your job more if you worked at a different company.
| bcrosby95 wrote:
| If you don't refactor, as you program new features the code will
| rot. The best time to refactor is when you add a new feature the
| codebase didn't anticipate - this is how we do it at my job. Do
| you not consider this refactoring? Or do you just bolt on things
| as you go?
|
| Or do you consider refactoring something like "OK, we have 2
| weeks to refactor the codebase" - because IMHO that's not a great
| way to do it. Instead, at work we follow the scout rule: make the
| code a little better each time you touch it. This is still
| refactoring.
|
| And we don't do sprints either. We just have a priority list and
| however long the next thing takes is however long it takes. We do
| rough estimates but don't hold people's feet to the fire. Rarely
| we have deadlines and things DO need to be done by a certain time
| for that, but that is due to external marketing/etc. This usually
| only happens a couple times per year.
| jasmer wrote:
| I like all the things you don't like!
| kace91 wrote:
| I am the exact opposite. I mean, I don't like processes and
| meetings, but I do like the planning and architecture part much
| more than I like actually writing code.
|
| Usually, if your mind is decently organized, I find that the
| problem is solved before writing a single line of code. If that
| happens, then the actual part of writing becomes dull and
| mechanical - the problem has already been solved.
|
| I've never understood people that just jump into coding without
| much of a plan - and I think the industry has shifted towards
| that a lot these past years. Everyone is used to learning by
| doing, and pretty much everyone seems to have an aversion towards
| reading and documenting. I feel I'm slowly becoming part of a
| minority.
| matsemann wrote:
| Hmm, I often feel lots of important details or edge cases are
| only discovered when you start programming. It's a reason
| waterfall was abandoned. Planning, prototyping and then making
| a more informed decision is my goto approach, instead of
| planning forever.
|
| Actually, I often feel the architects that think they've "fully
| solved the problem" are full of themselves, and just not smart
| enough to realize all the things they've not yet thought about.
| guywhocodes wrote:
| Yeah this is quite common, somehow I sympathize with both gp
| and submitter here, the last year I have tried suffered under
| a group of architects that have greenlit a project where we
| have now wasted about a man century. All because we ramped up
| fast into a "fully sovled problem" with new "well understood
| architectural patterns and design philosophy". And these are
| not "23 year old CTO" type people, it's people with 25+ years
| as "enterprise architect" in FAANG type companies.
|
| The main lesson I've drawn is that never propose a technical
| solution that you didn't PoC and that you only have validated
| the parts of the system you implemented. Deletion is often
| harder than creation.
| yamtaddle wrote:
| I'd agree that an awful lot of the problems I run into are
| dumb trivial shit, once the "real work" starts.
|
| This Android component doesn't allow styling without
| modifying the library object itself, for no good reason aside
| from whichever intern wrote it was lazy and nobody at Google
| cares about anything, so it made it through.
|
| Ulimit exists, guess I should go fuck myself.
|
| AWS says it supports this language for lambdas but it _kinda
| doesn 't_ if you look at the bug tracker for the tools.
|
| This fancy new build tool someone else chose breaks this
| third party package in a way that goes away immediately if I
| just swap it for the old, uncool build tool.
|
| That kind of crap. And it's the worst part of programming.
| There are also "real" problems, but they're the minority.
| lvmz wrote:
| Problems are often "sticky" (A term I've read referencing
| this exact thing, a problem where you need to begin
| implementing before you understand it fully, but I don't
| think it's a widely used term) but I think the implementation
| step is a different matter than architecture stuff
| regardless. It's not that there aren't important things to
| work out, but for me I broadly consider that to be part of
| the implementation.
|
| I get what you're saying though, I definitely don't think I'm
| solving all my problems before ever starting the code, but I
| definitely always finish solving the problem before I finish
| the code, and usually early enough that the rest of
| implementation drags even if there are quirks and edge cases
| to work out.
| kace91 wrote:
| > It's a reason waterfall was abandoned.
|
| Waterfall vs agile is not really about how much effort you
| put into design, it's about how long the plan-code-reassess
| cycle is.
|
| You should not plan a whole year ahead and then act, it's
| better to plan the next couple of weeks.
|
| But you still need to define how the work for those weeks
| fits in the system, the load it's expected to take, the
| metrics that tell you it's working, how to roll it back if
| you screw up, etc.
|
| I find that many people use agile as an excuse to ignore
| these questions and just pile up fixes on top of prototypes.
| randomdata wrote:
| _> Waterfall vs agile is not really about how much effort
| you put into design, it's about how long the plan-code-
| reassess cycle is._
|
| Read the Manifesto again. You will notice that is actually
| about the considerations you should take into account if
| you want to run a software team without managers. Each
| point is there to ensure that the necessary functions a
| manager would traditionally take care of still get done.
|
| Waterfall never existed as some kind of formal process. It
| was invented as an illustrative device.
| kace91 wrote:
| > Read the Manifesto again.
|
| I did, and here's the direct quotes:
|
| > Deliver working software frequently, from a couple of
| weeks to a couple of months, with a preference to the
| shorter timescale.
|
| As I said, the cycle length is shortened, yet...
|
| > Continuous attention to technical excellence and good
| design enhances agility.
|
| ...design is not removed from the process, but kept as a
| cornerstone.
|
| > Simplicity--the art of maximizing the amount of work
| not done--is essential.
|
| This one might be a bit more of a stretch, but I see here
| the benefit of designing a simple, elegant solution
| rather than doing work straight ahead.
|
| In any case, I don't fully agree with the agile
| manifesto, even when correctly implemented. Particularly
| this quote is the bane of my existence:
|
| > The most efficient and effective method of conveying
| information to and within a development team is face-to-
| face conversation.
|
| Which you can identify as the very opposite of the ever
| popular 'this meeting could have been an email'.
| randomdata wrote:
| Now read it again as the entire document that it is.
| While I can see where you are coming from, your theme
| doesn't carry into the points you conveniently left out.
|
| Once you put it together, you'll realize that the message
| is:
|
| 1. Deliver software. You won't have a manager hounding
| you to do so.
|
| 2. Do good work. You won't have a manager questioning
| what you've done.
|
| 3. Don't spend more time programming than you need to.
| You need time for managerial tasks.
|
| 4. Meet with your teammates. You won't have a manager to
| act as the go-between.
| TheRealSteve wrote:
| Being a developer without a good Engineering Manager is a
| futile exercise in my experience. Software developers
| deliver quality work and solve problems efficiently as a
| matter course. If not, they should be let go to work
| someplace else, potentially outside the software trade.
| Saying those skills are exclusive to followers of the
| agile manifesto is silly. Find a good manager that brings
| you opportunities and respects your expertise. If your
| manager hasn't put you in a place to be the rock star in
| the last year or so you need to move on or accept you
| aren't "all that".
|
| My opinion is based on being a software engineer (junior
| through principal) at small, medium, and fortune 100
| companies. I also have years of experience as an
| engineering manager.
| randomdata wrote:
| _> Saying those skills are exclusive to followers of the
| agile manifesto is silly._
|
| What says that? The Manifesto is there to help guide you
| if your group chooses to forego managers, but it doesn't
| suggest not having managers is the right tool for the
| job. An engineer more than anyone should understand the
| concept of tradeoffs.
| Aeolun wrote:
| > Saying those skills are exclusive to followers of the
| agile manifesto is silly
|
| It's silly to be absolute about it, but I think there's
| probably a large overlap between competent engineers and
| people that agree that the agile manifesto is generally a
| good thing.
| TheRealSteve wrote:
| That's fair. In that spectrum I'd rank folks that see
| agile as but one tool in the shed higher than those that
| agree it's _the_ way to execute projects.
| icedchai wrote:
| Exactly this. Agile is often seen as an excuse to throw out
| any sort of design. You wind up with fixing the mess made
| last sprint in the next. But, good news, there are Jira
| tickets with points assigned for the half-baked fixes!
| escapedmoose wrote:
| True, so if you're a planning type of person, you need to
| have realistic expectations about your unknown unknowns.
| Humility helps. But the people who go straight to the
| keyboard to figure it out as they go can spin their wheels
| just as bad.
| birdyrooster wrote:
| I dont know about you but virtually every team still uses
| waterfall at some scale
| [deleted]
| busterarm wrote:
| I'm with you too here. I always chafe and find minor conflict
| with the types of engineers that just want to head down,
| headphones on and write code all day long.
|
| Planning is like 80% of the work to me.
| mixedCase wrote:
| Would it help if, as someone on the other side that for the
| most part only plans as the feature is discussed on their head
| and then jumps into code, I say that the code is where I
| "document" my plans as types, comments, tests, and stubs, which
| I progressively expand into implementations? On the same vein,
| I'd add that some languages greatly facilitate this process,
| while others make it more of a pain.
| 8n4vidtmkvmk wrote:
| I don't think that counts. I love code but code doesn't
| capture the "whys". It's also not very good at giving an
| overview of the problem.
| mixedCase wrote:
| The "why" is pretty much the only reason to write comments!
|
| Overviews of the problem are more in the realm of spec
| rather than implementation planning and is another issue
| altogether. Of course you need to know what you're solving,
| but it is my point that I don't need to write a detailed
| document on _how_ I 'm going to solve most everyday
| problems when I can jump into the code and progressively
| work from there using the tools provided by the language.
| harrego wrote:
| I am stunned by how close this description aligns with my
| thinking. I think that reading and prior consideration are fast
| fading in this industry for the reason you put so well,
| "everyone is used to learning by doing."
| 8n4vidtmkvmk wrote:
| I sometimes start coding without much of a plan. Then I get a
| little ways in, start seeing all the problems, start jotting
| down solutions with pen and paper and then realize hmm.. maybe
| I should write a proper doc and solicit feedback.
|
| It almost works except that no one _really_ understands the
| problems you 're presenting because they've all got their own
| problems to deal with. It's more helpful as a duck.
| hk1337 wrote:
| I feel like I am in between. I learn better by doing but I
| think everyone thinks they have to move so fast, be agile, that
| they leave their shitty implementation doing the work instead
| of figuring out how to rewrite it into something more
| manageable.
|
| You have to do the stuff you don't like to get to stuff you do
| sometimes.
| rytor718 wrote:
| This is when programming really clicked for me: I learned that
| if the problem isn't well understood and solved before you sit
| down to write a line of code, then its not time to code yet.
| Model the problem space first.
|
| And as another commenter chimed in, its true that some problems
| only emerge once you start writing the code. But that's
| alright, its part of the process. The planning isn't so much to
| figure out every problem ever, but to model the known problems
| so that programming the solutions can begin. I go back and
| forth between white-boarding and coding as things emerge.
|
| I always tell myself that if I'm sitting at the keyboard and I
| don't know what to type, it's time to go back to the whiteboard
| because I'm not understanding the problem.
|
| edit: clarity
| ahartmetz wrote:
| You might want to become some kind of technically minded
| product manager? Good people seem to be especially rare
| (therefore valuable) in product management.
| meese712 wrote:
| > I find that the problem is solved before writing a single
| line of code. If that happens, then the actual part of writing
| becomes dull and mechanical - the problem has already been
| solved.
|
| I can relate to this so much sometimes. Right now I'm putting
| off programming because the ticket I have I've already thought
| through in my head and now I'm sitting here goofing off on here
| and reddit because I just don't want to do the actual work
| part.
| rlt wrote:
| It's interesting how opposite people in nominally the same
| profession can be.
|
| If the problem is solved before I write code I'm not really
| interested in writing code. I crave problems that require
| experimentation, where the solution isn't obvious.
|
| On the other hand, it's a reason I have trouble completing
| projects. Once I prove to myself it's feasible I get bored with
| finishing it...
| flatline wrote:
| Early in my career I started out just writing code for every
| problem. Now I loathe the prospect of writing a line of code
| unless I'm sure it's not a waste of time. It can be exploratory
| code, but I need to know in advance exactly what questions I
| want it to answer, so even if I throw it away it definitively
| tells me a path I should not go down.
|
| I think this is a pretty common career progression. Coding can
| be fun and rewarding but I've written hundreds of thousands -
| possibly millions - of lines of code in a dozen languages and
| there is very little novelty left for me. The challenges of
| team organization, project planning, and personnel issues are
| more attractive right now.
| cratermoon wrote:
| > I think this is a pretty common career progression
|
| You'd think that, but I worked with a guy going on 20 years
| of experience who seemed to be the embodiment of code first,
| ask questions later. He coded quickly and abundantly, but man
| it was crap code. He'd get assigned a story and go off and do
| what he thought it said but more often than not missed the
| real point of what the request was.
| yamtaddle wrote:
| Agreed. These days every time I'm writing code I can't help
| but feel it's because I didn't know enough to be able to
| avoid writing it.
| crgi wrote:
| Same for me. Jumping into the code can be fun at times. But if
| the software is not modelled well, a lot of bugs will orginate
| from structural issues. When you see those, the bugs become
| anoying to fix because you basically know new ones will pop up
| eventually since the root cause is not adressed. Applying
| concepts like DDD will be of very little value without a
| profound understanding of the domain at hand. This is mostly
| established by non-coding activities.
| escapedmoose wrote:
| I'm with you. Everything gets scribbled out on paper before I
| touch the keyboard. And I've documented most of the solution
| before finishing half the code. It's niche that we can find a
| niche at least :)
| Aeolun wrote:
| > I've never understood people that just jump into coding
| without much of a plan
|
| Have you worked on problem spaces that are either so vague, or
| so large that it's impossible to form a mental model?
|
| That's when I just jump into coding, because there's no
| alternatives. Whatever I produce will make the powers that be
| able to crystalize what they actually want.
| t43562 wrote:
| Absolutely. The act of trying to write code immediately
| brings out the questions that you end up needing to answer in
| a design.
|
| The mistake is by other people who think that your first
| efforts represent the product and need to be shipped.
| chinchilla2020 wrote:
| Unfortunately, it takes 6 months to a year to fully cultivate a
| strong culture around a process.
|
| Two factors cause this to be an exercise in futility:
|
| 1. Job mobility
|
| People are incentivized to job hop. Most employees are ramping
| into a new role, coasting/leetcoding while they interview
| elsewhere, or preparing to transfer to a new role in your
| company.
|
| In a 1.5 year employment window in a given role, a team member
| may only be getting 6 months of productive time in the new work
| paradigm.
|
| 2. Capricious Management culture
|
| The new era of tech has ushered in a fickle type of boss who
| has constant pivots, realignments, and shifting priorities.
| They speak of some utopian future for your organization and
| paint a picture that everything is always 'in transition'.
|
| This means that nobody seriously considers your CICD or Agile
| paradigm to be a permanent thing... you only get half hearted
| attempts to follow it for the 8 months that it lasts before a
| new paradigm is forced onto your group.
| ozarker wrote:
| I'm relatively young in my career, <5 years experience. I did a
| year at a company that forced me into meetings and planning for
| huge chunks of the day, nearly every day. It really made me
| develop a hatred for agile and all the process bullshit.
|
| Recently this year I switched to a job that gives me hard
| problems to solve and turns me loose on them. I still need to
| attend standup and planning meetings but management is very hands
| off and respects my time. My productivity and love for my job has
| multiplied incredibly.
|
| I think management can be a force multiplier or a complete anchor
| depending on their attitude. Some people need to be managed to be
| kept on task but for a lot of us who have a love for programming
| a hands off approach is much better in my opinion.
| mvaliente2001 wrote:
| May I suggest you to take another look at refactoring? I think
| that if you love unit testing and debugging, you probably would
| love refactoring too. I like that I don't have to worry to find
| the perfect name for my functions and methods _on the first try_,
| and that I can focus in making code that works first, and after
| that I can worry in making clearer and more understandable.
|
| Now, to be fair, I also like the common practices in the industry
| too. Scrum or kanban, ticket creation and estimation, and daily
| stand ups. When you're part of a team you need a lot of
| communication and effort to keep everybody working in the same
| direction. Besides, managers want to be kept informed. The how is
| not as important as the why.
| icedchai wrote:
| Things were better before agile / scrum / annoying processes took
| over.
|
| Not all companies were waterfall, they kind of just "did things"
| without any well defined process. This was how things were until
| roughly the early 2010's. I remember working for weeks, after a
| couple of whiteboard sessions. You'd meet about what you were
| going to do, work on it, and come back a week or two later.
| Occasionally there would be informal check ins.
| hk1337 wrote:
| Things were better before agile / scrum moved from the
| developers doing it to project managers doing it.
| t43562 wrote:
| "Project Management" and "Agile" IMO are completely opposed
| concepts so no wonder project managers don't get it. They
| still want jobs however so now presumably it's perverted
| agile.
| commandlinefan wrote:
| > Things were better before agile / scrum
|
| I don't necessarily agree that things were better - but "agile"
| was supposed to fix the things that were bad back then but has
| since somehow managed to morph into exactly the same problems
| that it was originally purported to solve.
| randomdata wrote:
| I always found it funny that where I worked we were doing
| Agile (without knowing it by that name) _until_ the "Agile"
| Kool-aid was drank, at which time processes started to trump
| people.
| commandlinefan wrote:
| Yep, when I first saw it, it was called "XP" (Extreme
| Programming). When I read the manifesto, I breathed a sigh
| of relief: finally, somebody with some authority has some
| clue about realistic software development! Then the Agile
| coaches started coming in: "the biggest benefit of Agile
| development is delivery of software on schedule and with
| budget!" Ok, new boss, same as the old boss. Gotcha.
| xiphias2 wrote:
| I read this all the time and see that software engineers don't
| even read the agile manifesto:
|
| ,,Individuals and interactions over processes and tools''
|
| What you are describing is the opposite of agile
| icedchai wrote:
| The truth is that the manifesto may as well be fiction. I'm
| talking about reality... what the industry actually practices
| as "Agile." That's why you read it all the time: because it's
| true.
| xiphias2 wrote:
| Maybe it's true at some companies, but it has nothing to do
| with agile / scrum, but letting non-tech people who love
| confrontation take over engineering leadership from
| engineers who are afraid of confrontation (which sounds
| like the disaster it is).
|
| Robert Martin (one of the creators of the agile manifesto)
| explains it quite well in ,,Clean Code'' presentation:
|
| https://www.youtube.com/watch?v=7EmboKQH8lM
|
| The whole presentation should be a must watch by all
| engineers so that they understand what _is_ agile to the
| point when they know it better than product / project
| managers / non-tech people.
|
| It's hard to get a better description than the original
| source, and no non-tech person has authority to override
| the real agile at that point.
| icedchai wrote:
| I'd be interested to know what percentage of companies
| are "true" agile. Based on my personal experience, it
| must be very low.
| xiphias2 wrote:
| It's not rare in my experience.
|
| It's basically a bunch of experienced engineers getting
| together for a weekend warning inexperienced engineers
| about newbie mistakes, like obsessing too much about new
| shiny tools / frameworks / processes created by people
| from the past, or leaving mess behind.
|
| At Google we were doing mostly agile actually (didn't
| really have any complex process, but had quarterly goals
| to check ourselfs and get feedback, also weekly check if
| we are going in the right direction).
|
| ,,this week'' snippets about what we're going to do this
| week.
|
| All light stuff to make sure that it doesn't hinder real
| coding work.
|
| Cross team work was much more messy of course, but inside
| teams this worked fine.
|
| At another small company I worked it was almost the same,
| we just didn't call it agile.
| [deleted]
| conatus wrote:
| > You'd meet about what you were going to do, work on it, and
| come back a week or two later. Occasionally there would be
| informal check ins.
|
| Planning meeting, ad hoc meeting doing the work then weekly/bi-
| weekly show and tells to show progress. Sounds like...some
| version of agile?
|
| Remember agile and the XP movement that preceded it was
| invented by software makers, who had observed the pattern you
| describe and decided to be self-conscious about it.
| icedchai wrote:
| It was true agile, not "Agile" in the sense we see today
| (empty ceremonies, time wasting meetings, micromanagement,
| endless jira tickets...)
| narag wrote:
| That's exactly right. There were good and bad things. Some
| method was needed, but too much method is lethal to
| productivity. Agile was sold as less rigid method, but for many
| shops it's simply too much.
|
| You need first to make it work, later to make it perform, then
| to optimize it, finally to trash and replace it. Many go right
| away to optimize then stall.
| grecy wrote:
| > _they kind of just "did things" without any well defined
| process_
|
| That's called making it up. While it may have worked for that
| organization, I assure you it falls it a heap 99.9% of the time
| large software is developed that way.
| Eduard wrote:
| > This was how things were until roughly the early 2010's.
|
| "Mid 2000s" for some of us at some places, unfortunately.
| amackera wrote:
| Before you did agile, were there ever death marches, slipped
| deadlines, pissed off clients, or long crunches?
|
| Your comment has the sparkle of nostalgia for glory days gone
| by.
| ryandrake wrote:
| Seriously. I think people are looking back at "no process"
| companies with rose-tinted glasses. Software doesn't just
| leap from the developers' fingertips onto store shelves. I've
| worked as recently as 2010 at a company with no software
| engineering process, no release process, no qa process, no
| feature intake process, no planning process, no bug tracker
| (!), no source control (!!), and so on. It was a total clown
| show. Highlight reel:
|
| Nobody knew what bugs existed or what features were needed
| until someone in sales who talked to a customer ran
| downstairs and recapped their last customer call.
|
| Builds were not reproducible. How we decided what we released
| to the world was we'd poll the room. Who could actually
| compile the software today without errors? That person would
| build whatever was on his workstation, debug symbols and all
| (because the release builds crashed), and package it up for
| the customer.
|
| How did we know what we were releasing works? There was one
| QA guy, who worked on the assembly line. They'd flash the
| software onto a single device, and make sure it still booted.
| Ship it!
|
| How did we plan what we were doing for the next N weeks and
| months? This one's easy--we didn't! The CEO or someone in
| sales would run downstairs and tell us "We just sold XYZ
| feature to a customer. We need everyone to drop everything
| and make this by the date we also negotiated with the
| customer!"
|
| I think "no process" software development only works for a
| single developer, or for a very small (less than 3 person)
| team of absolute experts. Mix a single junior person into the
| team or add more than 3 or so developers, and it's going to
| be chaos.
| SillyUsername wrote:
| Couldn't agree more with this and above poster. Having
| weekends back by less failing systems caused by cowboy
| unreviewed code and no crunch caused by inadequate planning
| are for me the main social benefits of agile.
| icedchai wrote:
| Yes. And sometimes those things still happen with "agile",
| too.
| SillyUsername wrote:
| "I like a few languages and I am not too keen on learning new
| paradigms or languages unless I have to"
|
| You're in the wrong job.
|
| A developer has to keep on top of tech industry or they'll become
| a dinosaur early and find trouble getting work after you lose
| your job (just ask Java devs who steadfastly refuse to move off
| anything but Java 8).
|
| Firefighting issues ("incidence response") due to lack of
| software engineering is not enjoyable when you've just manually
| deployed to production from your desktop computer and put the
| wrong build on that has migrated a prod db schema used by
| millions of people to one that isn't compatible with the rollback
| version of the software. And you'll be fixing it across your
| holiday and weekends.
|
| There's a reason these processes are in place - and its to stop
| the wild west cowboyisms bringing down the company.
| ur-whale wrote:
| You need to find an SRE job, it involves lots of what you enjoy
| and a lesser dose off the architecting things.
| jay-barronville wrote:
| What exactly is your definition and/or interpretation of software
| engineering? And how exactly, in your eyes, is it different from
| programming?
| codetrotter wrote:
| I've said it before and I'll say it again :D
|
| A programmer is a person who writes program code.
|
| A software engineer applies engineering principles when
| designing and/or implementing programs.
|
| A computer scientist uses scientific methods and rigor when
| solving problems relating to computing.
| vouaobrasil wrote:
| > What are some good jobs for a person like this?
|
| Academia, using programming in another science. You can program
| all you want there but you never have to do anything like
| software engineering.
| Eliah_Lakhin wrote:
| I prefer to use term "programmer" to describe to people who I am,
| rather than "software engineer" etc. And because programming is
| what I truly love to do.
|
| Even though, in my resume I use Software Engineer/Developer of
| course, because "programming" does not bring you money.
|
| Why so? To be honest, I think that we, the programmers, rarely
| make real things. Real developers make buildings, software
| developers do not make anything real rather than text on computer
| screens.
|
| In its root the purpose of programming as a job was developing
| programs that would automate processes of real economics. E.g. to
| automate industries(manufacture lines) or maybe to optimize
| transportation logistics. Today's economics is post-industrial
| economics. Basically, the economics that focuses on control of
| human attention and selling this "control" to other actors.
| Computer technologies is a big part of it, but it is loosely
| connected to automation.
|
| Only a limited number (a big number, but still limited) of people
| are capable to program. This is quite specific kind of mind. And
| only a small subset of programmers are capable to think in terms
| of programming and in terms of how to influence other people (the
| true value of post-industrial economics) at the same time. So,
| the ordinary programmer, to be honest, does not fit well in this
| system.
|
| On the other hand there are a lot of people who can't program,
| and they loosely understand computer systems, but they are good
| at the art of spreading influence. These people are primary
| agents of post-industrial economics, and they are truly rule this
| system. They occupy high positions in companies and corporations,
| and they spread their way of thinking and ways of management to
| other minorities (including programmers).
|
| We, the programmers, have to deal with this situation somehow if
| we want to have our part of the economic pie. Perhaps, through
| the trade-offs and compromises. But we have to admit that we are
| only minor cogs in this system. That is how it is in the current
| Economic Formation.
|
| Looking for better jobs in companies that value pure programming
| would inevitably imply of looking for companies that don't
| perform well in the post-industrial economics.
|
| The solution that I see is to do an ordinary "software
| engineering" job the way the rulers of the System want us to do
| it, and in the way we don't like to do it. At the same time we
| can working on the stuff that we love, and in the way we love to
| do it solely (or maybe with cooperation with other programmers).
| This is the best practical compromise that I can think of.
| dools wrote:
| You would probably love being an independent security researcher
| if you can make a living off bug bounties.
| commandlinefan wrote:
| Ha, I love programming and bug fixing, but I also love
| refactoring and rewriting. I even love writing unit tests. I
| can't say I care much for the "estimation" part of software
| engineering, because I don't believe it's a realistic goal - or,
| at least, I've never met anybody who could do it. (I've met lots
| of people who insist that I have to do it though).
| cbtacy wrote:
| This is what we used to call a "code artist"
|
| A good job tends to be one not in software
| felipellrocha wrote:
| I'm with you. I would also say refactoring, and rearchitecting
| can be fun. It's sprinting, and agile that really gets to me.
| I've considered moving away from the job.
| Scubabear68 wrote:
| A lot of startups fit this bill, or otherwise small companies.
| But you do need to dig into the company to be sure, I have seen
| very heavy "agile" processes dripping with bureaucracy get
| installed in surprisingly small startups (with predictably bad
| results).
|
| Ask around places (like here!) what their SDLC is like, and if
| they ask you what an SDLC is you may hit onto an ideal company
| )or the worst possible one :-) ).
|
| Probably don't bother with consulting or services firms. Look for
| industries that can benefit from software but maybe doesn't have
| big "enterprise" players yet. Consider areas like embedded and
| IoT where you can pretend it's the 80s and you are shoe horning
| features onto tiny CPU's with little RAM.
|
| Alternatively, code as a hobby on the side, if you have the time
| and will power for it.
| FpUser wrote:
| Simple hints for your type * Find smaller company
| * If possible find company that does some real business and needs
| software to run it. These are the best from my experience. I am
| not an employee but this is how I find my clients. * If you
| hear words agile, process, methodology start from the beginning
| * On the interview you should be asked what have you accomplished
| and how, how you could help to solve their problem. * If
| instead they would start grilling you on what that tiny dot in
| this particular language means, ask you to complete particular
| tests, write code during interview start from the beginning
|
| Obviously you should have some portfolio, some verifiable
| references and know what you are doing.
| nigamanth wrote:
| You could get into another field of programming, AI is coming up.
| allenleein wrote:
| This. I hate Xcode and all the dev tools built by Apple, but I
| enjoy writing software in SwiftUI.
| selimnairb wrote:
| Software development in a research setting might suffer from too
| little process, but I imagine would be a breath of fresh air to
| you. It has been to me.
| misfit_brown wrote:
| I hate the egos fight. Love programming <3.
| tarkin2 wrote:
| I wouldn't place all the blame on sprints, fauxagile, etc.
|
| The industry is driven by fashion and medium.com-led development.
|
| If you're not jumping on the in-vogue band-wagon then you'll be
| punished.
|
| After a while you've seen it again and again and you want to
| avoid it. But that puts you at odds with the industry and
| employers.
| adv0r wrote:
| the other way around
| 8n4vidtmkvmk wrote:
| Yes.
|
| Although I'd argue that refactoring and rewriting are part of the
| _programming_ fun.
|
| "sprint", "agile", design docs, red tape, bureaucracy, policy,
| and meetings are the crappy part.
|
| I just want to write code. I will work on the most boring
| problems. I don't care. Hard or easy. Features, infra, whatever.
| Just let me write beautiful code.
| ravenstine wrote:
| Yes, I have come to have a hatred towards software engineering. I
| will probably always be a software engineer because it's still a
| better job than many, and because I like programming. But holy
| hell, there are so many problems with this profession and a real
| lack of interest within the industry in terms of actually
| maturing it.
|
| Pretty much every problem an engineer deals with on a daily basis
| is either self imposed or imposed by other engineers. Most of the
| problems aren't even real problems because most real world issues
| have already been iterated upon. Most of what we do is fixing our
| own mistakes. Being a software engineer sometimes feels like
| being a self-licking ice cream cone because, if it weren't for
| all the new frameworks and the lack of effective team
| organization, a substantial fraction of us would have nothing to
| do. Well, besides hobby coding, which I guess can be a good
| thing, but I don't even know that many programmers who actually
| code anymore as a hobby.
|
| What needs to go away are most of the paradigms that still get
| pushed around.
|
| The tools themselves are actually pretty good. We have speedy JIT
| languages, package managers on every OS, no more Internet
| Explorer, awesome free IDEs, and more help and documentation than
| ever. What's gone horribly wrong is believing that we need _more_
| tools for _every_ task domain. A mistake we 've made is believing
| that X is "considered harmful" and to only apply the "best
| practice" in every nook and cranny no matter how insanely
| complicated things become. We've made the mistake of believing
| every problem is a matter of scale and almost never _poor
| engineering_. Poor engineering? _Impossible!_ That is unless it
| 's that of the _guy who came before me and left the company._
|
| I can go on. Why do we still use frAgile methodologies all over
| the place when no one can adequately measure whether it's more
| effective than another workflow? Why is it that every single
| company I work for ends up using Scum methodology but never
| bothers actually measuring whether performance improved as a
| result? Why are we so opposed to documenting our work? Why do we
| keep bending over backwards to make websites behave like
| applications and still screw it up most of the time? Why are we
| obsessed with code coverage when it's only weakly correlated with
| the number of bugs that manifest? Must we keep adding more and
| more lint rules?
|
| To top it all off, it doesn't matter what you think unless you
| are one of the 10% that has a real say in how a codebase is going
| to take shape. The reality is most software engineers have
| limited capability to take the initiative for change.
|
| But hey, it's a good profession no matter how crazy it can drive
| you sometimes. I'm not saying people should do it forever, but we
| can do a whole lot worse.
|
| At the same time, we ought to be doing a lot better. With the
| exception of AI/ML, I believe software engineering is in a bit of
| a dark age.
| myth_drannon wrote:
| You don't like jobs not software engineering.
| barrenko wrote:
| Valid point.
| ThinkBeat wrote:
| I come from an era when not liking your job was the way things
| were. You could enjoy the social camaraderie, lunch and your
| paycheck. The army did an excellent job of preparing me for that
| situation.
|
| With all that said I do love programming the way it used to be.
| You could often be allowed to write something pretty. (From a
| pure code perspective)
|
| At the uni. I had that freedom as well.
|
| These days solutions usually surround using duct tape, plastic
| straws, and a half-broken welder to force various components and
| 3rd party APIs to work together, even though they are usually
| never designed to work in that way.
|
| Then a vendor changes its API, we need to connect to yet another
| service, and some people who see resume padding as their biggest
| goal in life will manage to throw the latest hyped products /
| frameworks / tool into the mix.
|
| It is a monumental task to write that code to be pretty.
|
| A lot of software engineers care a lot more that we are using the
| latest hotness than they do about making it pretty.
| cat_plus_plus wrote:
| The purpose of commercial employment is to do something useful
| for others, not personal enjoyment and self fulfillment.
| Obviously, enjoyment and self fulfillment can be coincidentally
| found at work, and there is nothing wrong with considering that
| as a factor in addition to compensation. But if you really want
| to 100% enjoy hacking, set time aside for a hobby. Retro
| programming like MS-DOS is one example where you will never be
| tempted to compromise fun for other considerations, since there
| is no practical or even charity market for end results. Plus,
| inherent platform limitations severely restrict bigger picture
| software engineering.
|
| Put it another way, say you found a hacking-only job. Would you
| enjoy commute, having to show up on time when tired, layoff
| worries, reprimands from manager, inevitable coworkers with
| personality issues? The only way is to code without commitments
| to others.
|
| Ironically, once you got your hacking fix in, you might reach a
| point where you run into limitations of coding without plan and
| structure and start appreciating early design reviews to avoid
| wasted work / code reviews to avoid get bogged down by a week of
| debugging that could have been an hour of hardening.
| Foobar8568 wrote:
| I hate entrepise softwares, matrix organizations, SaaS products,
| sales teams and sales architects but I enjoy developing, making
| products, helping business users, so these days, I am wondering
| why I even stay in this fields. Switzerland is a rather small
| market, and I don't feel that going back to France would be
| great. So just stuck in my daily routine...
| Acrobatic_Road wrote:
| Programming ought to be called software engineering.
| paxys wrote:
| Sounds like you hate having a job. You'll just have to do what
| most people on the planet do - suck it up and bear with it. It
| would be great if we could solve fun programming puzzles all day,
| but there are bills to pay.
| donutshop wrote:
| Being too reliant on Atlassian products ruins the fun. Blindly
| following patterns aren't necessarily fun either.
|
| Personally I think I enjoy solving problems with just enough
| tech. I roll my eyes when I see hyped tech/practices tossed in
| with everything. I know somebody that works in a hospital as a
| unit clerk, and they supposedly use JIRA and are Agile.
|
| In short, there's a lot of fake work.
| mindcrime wrote:
| _Do you hate software engineering but love programming?_
|
| Nope. I love the engineering aspects that go beyond "Just
| programming". I don't always agree with some of the details of
| how those processes work, but it's all fundamentally important
| stuff and I enjoy working on it. I do like to keep processes as
| lightweight as possible though.
| rr888 wrote:
| Sounds like most of us you like developing but dont like working
| in other people's code and design.
|
| Corporate work has a bad reputation but lots of upsides. I work
| in a small team of 5 people on a system that has about 40 users.
| Its amazingly better when you can talk to everyone, know what all
| the users want, dont have to worry about constant uptime or
| scalability. Flexibility and budget to pay for good platforms.
| Just dont talk about the refactoring - rewrite from scratch!
|
| Reply: Yes it is expensive, the users are all paid more than us
| though which means we're helping them be productive. I have to
| add we also own a second application that has about 100 users
| that we spend some time on maintenance and support.
| osigurdson wrote:
| >> 5 people on a system that has about 40 users
|
| Gosh, that is expensive software!
| btown wrote:
| Or a _really_ really value-add internal tool!
| zabzonk wrote:
| not so much. at the last investment bank i worked at we had
| about 10 developers writing code to support about 10 traders,
| perhaps a few more. i don't think this is unusual. this is
| complex stuff that is changing all the time due to regulatory
| and business issues.
| ghettoCoder wrote:
| That's weird way to look at it. It's about value, not cost.
| For all we know that 40 user system manages the entire
| logistics of a national shipping company and saves them 50x
| the ops cost. Still think its expensive? Or maybe it's a
| corporate risk register with significant potential regulatory
| and reputational harm attached to each risk. Still costly?
| osigurdson wrote:
| I didn't intend to suggest that the software does not have
| a positive ROI.
|
| Some applications (control systems, etc.) have no users the
| traditional sense.
| rco8786 wrote:
| Seriously. It's hard to imagine a group of 40 people that
| would need a sufficient velocity of changes/new features to
| warrant 5 full time engineers.
| pillefitz wrote:
| Any trading application, where markets are constantly
| changing, new financial products included, new models
| developed etc.
| shmatt wrote:
| From my experience, this is pretty common in AI
|
| Internal tools used by a dozen or a couple dozen AI
| engineers/Data Scientists, the models they output used by
| millions. It's totally worth keeping 5-10 person
| engineering team to create better and stronger tools that
| make upgrading and deploying new models easier and faster
| time_to_smile wrote:
| > totally worth keeping 5-10 person engineering team
|
| I've worked in AI/ML for a long time, and I can tell you
| that in all but the rarest of exceptions nobody has sat
| down and done the math to really determine if that value
| is there. In my experience, most cases it's not.
|
| I've seen teams like you describe and then asked them
| "what's the difference in value between what our model
| does today and the theoretical optimum"? The answer,
| which nobody liked, was fractions of a penny per user.
| That means if the team achieved perfection it wouldn't
| really matter in practice.
|
| We're going to see a lot of the AI/ML teams disappear as
| companies are forced to focus on determining the real
| value add being provided.
| xmaayy wrote:
| Massive corporate HR Dept with custom rolled software. Bank
| team with software for compliance. Endless possibilities...
| cloverich wrote:
| Imagine each of those people is an employee at the same
| company, and they each command a salary of say 100k. How
| much more productive do you need to make them for it to
| become worth it? If you 3x their productivity, they are now
| doing the job of 3 people, you just saved 200k _per year_.
|
| To tie that back to your comment -- imagine its for a team
| of 40 users but the company would ideally like them to be a
| team of 400 users. Yet because of the software being
| created, those 40 people are doing the work of 400.
|
| You can extend that line of thinking pretty far -- and
| going down that line of thought is when I realized how
| valuable programming is. When you build the right things
| you are literally creating value with everything you ship,
| and it adds up over time.
| osigurdson wrote:
| >> when I realized how valuable programming is
|
| Definitely. A cheap computer can outperform a billion
| humans at certain types of tasks. One must merely find
| the right tasks for the computer in order to exact
| unfathomable value. AI is going to expand the problem
| domains that computers can compete in by several orders
| of magnitude. The era of SPUs (Single Person Unicorn)
| companies is near.
| TillE wrote:
| Every company needs internal software of some description,
| and sometimes you're doing unique stuff that can't simply be
| purchased off the shelf.
|
| I mean the extreme case is a developer writing scripts they
| only use themselves, which would be a 1:1 ratio.
| jsty wrote:
| Surely the extreme case is whole teams working on software
| only one person uses
| cratermoon wrote:
| Oh that's nothing. I worked on a project at a fortune 500
| footwear company with dozens of developers, FTEs and
| contract, that worked over a year on just an update to a
| software package that was used by maybe 5 people at the
| company. Granted, these 5 people were the folks actually
| designing and figuring out how to manufacture their shoes,
| but still. At least 20% of the contractors were just warming
| their chairs, and more than one were what I call net negative
| producers: anything they wrote had to be corrected by someone
| else before it could be called done.
| francisofascii wrote:
| You are probably right, but not nearly as expensive as the 40
| users (assuming employees). So if you can double their
| productivity it is worth it.
| varjag wrote:
| It could well be this software is what makes it 40 users
| and not 4000.
| onion2k wrote:
| You can't tell that from the data provided.
| worldsayshi wrote:
| I mean you're right but also; what does a manager do if not
| producing "software" to a small group of individuals. Or a
| designer for that matter.
|
| Anyone who produces direct output to a small group of people
| is expensive in a similar way.
| tome wrote:
| There's a really interesting phenomenon at play here whereby
| osigurdson said that something was expensive (and it's
| probably about $1M/year/users) and everyone has replied as
| though he/she said that it was _too_ expensive.
| baby wrote:
| Tangent, but I realized the same thing about competitive gaming.
| Games can be a lot of fun when you're playing with noobs and
| you're a noob yourself. But when you get good and start playing
| with good people then there's all these things that you need to
| do all the time and that you need to be aware of. It demands a
| lot of focus, and rigor, and poop shoveling type of redundant
| tasks (e.g. always zigzaging when you walk to avoid snipers) that
| a lot of the fun is lost. But of course, competing at a high
| level is something that's also much more rewarding, and in that
| sense shipping a serious product that's used by many people is
| much more rewarding to fucking around. Doesn't mean you can't do
| both. Maybe that's why I have so much fun when I discover a new
| language or framework.
| Existenceblinks wrote:
| To me, the cult part is the worst in this industry. Job market is
| rotten and it spreads to how programming is adopted. In short,
| cult -> demands of mediocre tools -> supply of idiots. Apology if
| the tone is too extreme to this post's theme.
| jconley wrote:
| I'm definitely a hacker/artist type vs engineer. I like shipping
| things, stumbling around, finding a path, not planning them out
| and executing that plan. By the time I've planned something I
| have to use all of my available executive function to force
| myself to do it.
|
| So I tend to gravitate to early startup life where it's all chaos
| and unknown and getting things done quickly is most important.
| mathteddybear wrote:
| A big tech company SWE, just join the Quality team, rather than
| Infra
| tsunamifury wrote:
| Every few months or so we get these really circle jerky posts by
| engineers who believe the world of business is them just pumping
| out code and somehow getting paid.
|
| 1) that's the difference between a job and a hobby. You do the
| hard parts you're paid to do sometimes.
|
| 2) decisions you don't like by stakeholders you don't like aren't
| always wrong just because you see some way to "code it". A
| product is not just its code base. It's is also the design,
| marketing, revenue and growth strategies. Sometimes even more
| than the code base. Sometimes code can solve these issues but
| more often it can't.
|
| 3) this view often attracts comments from engineers who seem to
| have very limited experience in building and running successful
| products that can pay the bills. It requires a lot of hard work
| you don't love. Yes you can find others to do that work but
| that's you. You're the one hired to do the work higher ups don't.
|
| If you disagree you can start your own business and learn for
| yourself. A business is a lot more that solving interesting
| problems and calling it a day. It's building, growing and
| managing a business and the tasks that go along with it.
| busterarm wrote:
| It's kind of like all of the threads that I've been reading
| from smart, well-paid engineers lately bemoaning that
| unprofitable startup companies should be offering softer
| landings for mass layoffs.
|
| They have all of this fuzzy thinking around how in this economy
| broken companies that can't raise any more money are going to
| somehow take out loans to give people a year of severance...
|
| No profession is immune from practitioners being completely
| disconnected from reality. We are not geniuses simply because
| we do X.
| DAVer98 wrote:
| [dead]
| arcturus17 wrote:
| I have my own solo consulting business. I outsource a lot of
| implementation so I don't code boring bits in production and
| don't have to touch technologies that I don't like. I code a
| little kata every morning, and do hobby projects as means of
| research, promotion, and to keep my skills sharp. On rare
| occasion I make individual contributions to production, but
| mostly when I choose to. This could all be fun for OP.
|
| But then I have to manage customers, project/products and above
| all, sell. I prefer technical stuff but I've learnt to find
| sales palatable, sometimes even exciting. More importantly:
| necessary. I am dedicating a fully focused and intense Monday
| every week (plus some residual follow-ups) at the moment, but
| even this moderate amount of dedication to business development
| (~15% of my working time) would probably horrify a lot of devs.
|
| I doubt a perfect job exists. It's trade-offs all the way down.
| Some people are suggesting academia but many people there
| complain about lower pay and lack of action.
|
| Like in engineering, choose your trade-offs, and take your mind
| off them or, hell, embrace them fully.
| sbochins wrote:
| Totally agree. The non-fun parts are usually the parts that you
| have to pay someone to do. I work on a pretty complicated piece
| of software with some interesting technical challenges. But,
| the most valuable things I can work on are around collaborating
| with other teams, integrations, and reliability. Would much
| rather work on some of the unresolved technical challenges.
| But, that's more hobby work, not work work.
| 015a wrote:
| And every time these posts come around, someone immediately
| jumps in and plays a character in Office Space, saying "oh the
| engineers don't like talking to people, that's why I'm
| valuable".
|
| Look at all the recent layoffs; get the data and ask around
| "how many Engineers with 1+ years of seniority were impacted by
| the layoffs". The number is _dwarfed_ by literally every other
| business function. Dwarfed. Your probability of getting laid
| off is, actually, seemingly, directly proportional to how close
| you are to the center of business function, process, and
| revenue. Sales? Big impact. Marketing? Gulp. HR? Ruh roh.
| Product and Design? Eh, some get laid off. Engineering? Least
| of all. Well, except C-Suite; not seeing a lot of CEOs impacted
| by the layoffs, weirdly.
|
| This is LITERALLY the companies saying you're wrong; that a lot
| of what you just said is a smokescreen fabrication invented by
| the people who _are_ being laid off to justify their paychecks.
|
| Which isn't me asserting that Sales isn't valuable, or
| Marketing, or any of those other functions. Hella valuable. Its
| just me going to bat for the other side: That comments like
| your's are insensitive to the very real fact that, in many
| organizations, Engineers are treated like extremely well
| compensated trash. Shit flows downstream, and in software orgs
| it really doesn't get more downstream than the engineers; so
| when they say "we need to re-architect this piece of the
| system" or "we need to add testing" or "we need process
| improvements around coordination with other teams" oftentimes
| they're the least-heard voice in the room. "Well, we have room
| for five epics this quarter, and product wants these four
| things done, sales wants these two, we'll include this re-
| architecture as a stretch goal".
|
| Your entire worldview of a healthy organization is born from
| the largest bull market in human history, in the wealthiest
| country on the planet. Everyone is a genius in a bull market.
| Whether your opinion will still hold over the next few years is
| something you'll get to discover. I'll say this, though: There
| are people who do real work, and there are people who stand
| next to the people who do real work. I would much rather be the
| former than the latter. Engineers do real work; product
| managers oftentimes do real work; designers do real work;
| sales, marketing, lots of real work; coordinators, project
| managers, middle managers, scrum specialists, jira consultants,
| not real work. These are all problems born of too much money.
| quickthrower2 wrote:
| You summed it up well about planning. Translations:
|
| "Plan" = Stretch Goal
|
| "Stretch Goal" = Not gonna happen
| ShroudedNight wrote:
| As an engineer, I've had both a fantastic people manager, and
| a fantastic project manager. They were godsends. They were
| also abnormally engaged _and_ empathetic. They both sweated
| the technical details of the project we were working on and
| used that understanding to operate as very effective
| negotiators and shit umbrellas. As a result we were clear to
| move forward very quickly on multiple fronts and ended up
| having the capacity to pick up a whole bunch of slack from
| peer teams that had marooned themselves.
|
| Good ones have tremendous amounts of value to contribute. Bad
| ones are the productivity equivalent of a ball-and-chain.
| Unfortunately, the cross-over point into net positive seems
| to be located noticeably higher than mean competence.
| carom wrote:
| No one is talking about running a business. We're talking about
| code bureaucracy. I don't like front end, still happy to do it
| though, the issue is mandatory meetings, code reviews, design
| docs, and tests to make a simple UI change.
|
| Run a business, talk to stakeholders, make sales, but don't
| make programming so unpalatable that it moves at a glacial
| pace. Tell me what to do then let me do the thing you pay me
| to, and that is to puke out high quality code.
|
| All of the code bureaucracy features have their place but I
| don't think they're needed for every change.
| t43562 wrote:
| Code reviews should be at least a chance for other team
| members to learn the code - and take responsibility for it.
| If there's a bug they should have spotted it and the heat no
| longer falls entirely on you.
|
| Tests similarly are about allowing other people to change
| things without fearing that they will break the code you
| wrote. Without them the pace of change becomes very slow or
| very buggy.
|
| It's just working with other people that's more complex than
| working on your own.
|
| The meetings are usually because nobody has enough
| information or enough authority to get things decided. We can
| fix that sort of thing up to a point in many ways including
| the agile idea of having a product owner to prevent
| stakeholders annoying developers.
| complex_exp wrote:
| That very well may be true, but what's wrong with trying to
| cheat the system and do only the fun part? Clearly some people
| manage to do just that. I generally don't care about making the
| business fly, I care about what I care about.
|
| A better discussion would be about what can you reasonably
| expect, for example you'll probably never lead a project which
| puts a limit on your salary. It may still be a good decision.
| Bilal_io wrote:
| > I generally don't care about making the business fly, I
| care about what I care about.
|
| That's not ethical at all.
| complex_exp wrote:
| Oh no! Talk to me when the corporate structure kicks you
| out with zero day notice.
| riceman1864 wrote:
| Thank you for commenting this. I feel like I'm taking crazy
| pills reading some of the other comments on this post, e.g. "I
| think we need to get nontechnical people OUT of our process"
|
| There are so many engineers out there that are basically
| coddled children who get paid handsomely to sit in a chair and
| write code, and have no concept of where their handsome pay
| comes from.
|
| Thankfully, this era is coming to an end and companies will
| be/are already taking a hard look at who is driving business
| value and who is not.
| pdntspa wrote:
| You're perpetuating this assumption that engineers are
| incapable of providing business value without all these
| nontechnicals that I am complaining about.
|
| When I started my career I was working directly with
| stakeholders and building them exactly what they wanted. I
| did design, I wrote the code, I handled the infra, I triaged
| the issues. I was happy, my stakeholders were happy, and my
| process was not all that different than what LEAN prescribes.
|
| Amazingly, we didn't practice scrum or agile or any of that
| crap. I'd have a meeting with stakeholders at the beginning
| of the project, then I'd go to work on it, and they would
| keep in touch. If there were major issues, another meeting.
| But that was it. My manager would check in periodically for
| more detailed status updates, or to weigh in on technical
| decisions, and provide additional feedback from stakeholders
| and VIPs. But that was it, we all owned our given areas.
|
| Next company, same thing. Outgoing CTO drops literally the
| entire codebase in my lap and my boss says, pretty much,
| "it's your baby now". I clean it up, refactoring and
| rearchitecting as needed, and now, something like 8 years
| later, it's still running. In fact, that company got bought
| by another company in Europe, they've fired all of their
| staff, and yet somehow my infra still runs and drives
| business value. (Granted, I am a little nervous that they
| don't seem to have anyone supervising it, but I quit them
| years ago and only know this because they are asking me to
| rewrite the documentation that they lost after I left.) Last
| I checked annual revenues were around $20mil, and I know this
| because my code is the scorekeeper.
|
| None of this could have happened if I was on a team with code
| school alum and a product manager and a scrum manager and all
| that bullshit. Whatever we would have made would have likely
| been leaky and broken and required the ongoing commitment of
| an entire team of people to run what should be an
| afterthought for _one_ SWE.
|
| A competent, talented programmer with deep knowledge of the
| machine can be a force to be reckoned with. But the business
| cabal cripples us, just as they like to blow out the kneecaps
| of anything that threatens their jaundiced power base. There
| are numerous successful projects out there that nontechnicals
| view as run by anarchy, yet, these things live on. The Pirate
| Bay is my favorite example, but you could say the same for a
| lot of open-source that is both important and lacking in a
| foundation or supervisory organization.
|
| Nobody can truly "own" the product any more, and all of
| software suffers. I think that it is vitally important that
| _every_ project be understandable and implementable by one
| person, because when you throw a team of technical halfwits
| at it important details get forgotten. And the machinery that
| has been built to cover for this: endless ticket threads,
| neverending meetings, the Office Space-esque interactions
| between a manager and their reports... all of this just goes
| away when you replace it with a handful of smart, motivated,
| talented folks that can operate independently.
|
| As much as the business world hates them, there are a variety
| of one-man shops out there driving real business value and
| making real products, but my bet is they aren't making much
| use of all the bullshit "modern" tech (serverless, a
| bajillion AWS services, etc) because of the very real cost of
| needing massive teams of people just to keep these clockwork
| code contraptions running.
| perrygeo wrote:
| Ownership, decision making ability, technical design, KISS,
| deeply understanding the system, direct communication with
| stakeholders, and personal responsibility. Good list! These
| are the qualities that consistently produce top-notch
| software. When given the opportunity, this is what good
| SWEs do by instinct.
|
| What's notable that in each case, the modern ticket-factory
| approach ("all that bullshit") is explicitly designed to
| eliminate or dampen these instincts. Diffusion of
| responsibility, top-down control, eliminating direct
| connections, everything is decided by committee, treating
| professionals like replaceable cogs, stay in your lane and
| do tickets.
|
| It's not just that engineers are very capable of delivering
| direct business value. It's that many of the "non-
| technicals" are actively involved in sabotaging the efforts
| of engineers to do so.
| pillefitz wrote:
| One day you're gone. Then what? I've seen man-years spent
| by multiple developers trying to understand the application
| of a lone-wolf developer, with the final decision to opt
| for a complete rewrite.
|
| Companies optimize for planability and mediocrity, even if
| it comes at a small premium and hurts those of us who are
| living and breathing code..
| softwaredoug wrote:
| Funny! I might be the opposite
|
| I like doing all the things that avoids the weird debugging and
| incident response. Maybe I'm old. I like lowering my mental load
| understanding a code base. Unit tests are annoying work, but I
| love the headaches they save. In the end, I love the feeling of
| being able to feel 'safe' changing and deploying code, and feel
| like it's going to be rock solid in production.
|
| Programming, on the other hand, is kind of a chore. And I'm happy
| to see CoPilot, etc...
| syntaxing wrote:
| It's going to sound a bit harsh, but what you hate is engineering
| discipline. Every engineer I know absolutely hates it but it's
| like being an adult. There's a ton of things that suck but it's
| important to do in order to survive. Most process suck and some
| are even bloated. But they're there usually for a reason (mostly
| good). No good product is sustainable without engineers with good
| discipline.
| wnolens wrote:
| That's my take, too. It's platonic ideal v.s. real life. The
| latter is frustrating, but it's.. real.
| actinium226 wrote:
| One thing that I find frustrating with engineering is that
| sometimes this discipline is followed very perfunctorily. I
| think that's where at least some of the complaints are coming
| from. One thing that tends to irk me is when I'm in a culture
| that doesn't take code review seriously, and just hits approve
| on every PR/MR/CS because it would be rude not to.
|
| It's not that the discipline is frustrating, it's the ceremony
| that's frustrating.
|
| That said I think you have a point.
| baby wrote:
| "Discipline" is the word I was looking for. I think that's the
| best word to describe the kind of engineering that splits for
| fun engineering with serious/for prod engineering
| gymbeaux wrote:
| Yeah. I love writing code, but working with others while doing it
| has usually been unpleasant. The recurring theme is that
| management doesn't understand how software is written, ignores
| tech debt, sets unrealistic and arbitrary deadlines, etc.
|
| I have worked places where it was pleasant working with others
| though, and those have been small companies. There always seems
| to be a lot of bullshit once a company reaches a certain size.
| leke wrote:
| The place I work at recently grew and have adopted this agile
| scrum thing. We had a course that prepared us for it, but if I'm
| being honest, I just don't get it. I mean breaking a feature down
| into smaller pieces, sure I guess that helps. MVP, sure I
| understand although however you explain it to the client, they
| always freak out when they use it for the first time. I guess
| this means they only said they understood when they didn't
| really. But then there are the meetings and they waffle on about
| numbers and improving performance. I mean, what am I supposed to
| do about that? Give me a task and I will try to understand it and
| do it in a timely manner. That's all I can give you. What exactly
| is it that you want?
| Raed667 wrote:
| Here is the trick with agile. Everyone involved needs to be
| working that way for it to have any chance of success.
|
| Even the client needs to be agile. Otherwise it is just
| waterfall with extra-steps
| throwawaaarrgh wrote:
| Research & Development, Academia. Gigs where you're paid to
| experiment and try things out at your pace. If you can find
| something super niche it can be similar. Helps to be an expert in
| your field / very smart.
|
| If you just want to 'get something out now', join a startup.
| They're full of amateurs churning out terrible code at a rapid
| pace with no thought to the future
| rabuse wrote:
| You'd be better off freelancing with that mindset, or working at
| a smaller startup where your role is more "full stack".
| willio58 wrote:
| I'll just say that a lot of jobs don't follow the exact agile
| sprint methodology. At my company we have weekly sprints which
| are just rough lists of what each of us will do, and there's no
| pressure to do more ever. And if I can't do something one week I
| just add it to the next week's sprint.
| 2sk21 wrote:
| Like you I was sick of software engineering but still really
| enjoy programming. I was fortunate enough to be able to retire
| early and I now enjoy programming a few hours a day on various
| personal projects and open source.
| fsloth wrote:
| "I'd rather get to value now by making something that just
| works(... and is tested)"
|
| IMO that is the gold standard for 80% of professional software.
| Ship. Fix bugs if needed. Ship.
|
| If your org wants to do pointless cargo cult process junk and
| this troubles you, switch employers. Preferably to a place with
| old steady hands.
|
| Software engineering is not the problem. Problem are orgs that
| invent pointless process and encourage the managerial types to
| get some more process in. Not all shops are like that (yet... at
| least).
|
| I suppose you can probe this at the interview. Too little process
| and too much are both res flags. Too little:no CI, no testing,
| that sort of stuff. Too much: like porn, you know when you see
| it.
| WesSouza wrote:
| To me it's a mix of passion and reality.
|
| I am passionate about programming, even the parts you don't enjoy
| like rearchitecting and refactoring, those mean "applying
| knowledge to solve a problem" which I really enjoy.
|
| I detest the bureaucracy around these (teams, requirements,
| deadlines, etc.), but those come as either life requirements (a
| company must make money in a reasonable manner), or the current
| status quo of your entire project and its teams.
|
| The latter at least can be resolved by leaving your company.
| orblivion wrote:
| The strangest thing is that I love refactoring, and I sort of
| assume that it's another one of those things that programmers
| love to do, but managers keep pushing us to limit our time and
| move on to things that are visible to customers. But now I'm
| wondering if that's not the case. Or maybe it's just the sort of
| programmer who loves abstractions and is cast as a
| "perfectionist".
|
| I'm currently getting my footing now as a contractor. If this is
| actually something that most programmers don't like to do, is
| there an angle for me to pitch myself as "The guy who will clean
| up your code base"?
| adra wrote:
| Contractors are generally paid to solve a problem, and you'll
| be hard pressed to find an employer that believes tchnical.debt
| is worth paying boat loads of money for. If this is your angle
| of interest, I'd look into "legacy modernization", which works
| in a lot of the same ways as code refactoring with the big
| difference that you generally also need to shift programming
| languages and computing platforms . I did a gig 10 years ago
| and learned enough Cobol to be competent but most of the work
| was learning the business domain, format shift code, refactor
| over and over.
| orblivion wrote:
| I mean yeah that's close enough and something that's crossed
| my mind as well. I didn't know it had a pithy title like
| that, I'll look into it. Glad I asked a stupid question and
| got a smart answer, thank you.
| fburnaby wrote:
| I have to disagree with other responses. I think you could make
| a career of this for the same reason management consultants
| can.
|
| You could swoop in and "fix" some stuff and then leave the in-
| house team not understanding what you've done. That sounds
| profitable. You might even get called back to fix things a
| second time.
|
| As with management consulting, I think it would at the system
| level tend to do more harm than good, even if you do good work
| and get paid well for it. I agree strongly with feoren that the
| code needs to reflect the in-house developers' mental models of
| the domain or everything will fall apart. If you fix things and
| then give them a bunch of processes and coding standards to
| follow, they will not do well and you will be thought of as
| some clueless architecture astronaut by them. But profitably.
| wry_discontent wrote:
| This is totally me. I love refactoring, simplifying and
| adjusting code to be easier to modify. I almost always refactor
| before adding features, since I can adjust the code to make my
| modifications easier to do.
| feoren wrote:
| > I'm currently getting my footing now as a contractor. If this
| is actually something that most programmers don't like to do,
| is there an angle for me to pitch myself as "The guy who will
| clean up your code base"?
|
| Absolutely not. Do _not_ go there. If you love the process of
| software engineering, the art of refactoring, building good
| abstractions, etc., then you need to have your own code; your
| own garden to tend. You cannot just parachute into an ailing
| codebase to "clean it up"; you need to build the mental theory
| behind it first, which means deeply understanding the problem
| being solved. If you are able to do this, you may make lots of
| changes which genuinely improve the code, and _you will be
| hated for it_. Because when you leave, nobody is going to
| understand why you made all those changes, and they 're going
| to think you're some enterprisey architecture astronaut who
| just made everything more complicated, even if they're wrong.
| You've just disconnected their mental models from the codebase
| and then jumped ship, leaving them with something they can no
| longer maintain. Now instead of bad mental models matching bad
| code, then have bad mental models completely divorced of this
| new "good" code. They're worse off. You cannot just "clean up"
| a codebase -- keeping a clean codebase takes a long time, a lot
| of background knowledge, and a lot of care.
|
| The best thing you could do would be to improve their own
| mental models, and guide them in improving their own codebases.
| But this is a completely different skillset, and I don't know
| how much money there is there. It requires them to accept your
| help, which is a _big_ ask.
| adamhp wrote:
| I love refactoring too. It kind of feels like what I imagine
| editing writing feels like. You've got the rough draft, but
| also so many lessons learned and can see the big picture now.
| Much easier to go back and write something cleaner after the
| fact. I kind of treat all of my code this way.
| neuronflux wrote:
| > is there an angle for me to pitch myself as "The guy who will
| clean up your code base"?
|
| You sort of answer your own question unfortunately.
|
| > managers keep pushing us to limit our time and move on to
| things that are visible to customers.
|
| So if a manager only values things visible to a customer, why
| would they hire an expensive consultant work on things that
| aren't valuable to them?
| orblivion wrote:
| They don't stop it they just limit it. It's very difficult
| for them to know the right amount but unless they're totally
| ignorant they know it's not zero. If the code is a mess it
| may become apparent to them that they need to increase that
| threshold for a spurt.
| CuriouslyC wrote:
| The guy who will clean up your code base isn't a viable role
| because then the team that works on the code day to day will
| have to re-learn where everything is. It can work when a
| company is acquiring new code to refactor during integration,
| since the refactor catches bugs and makes engineers become
| familiar with it, but that would be done by people staying with
| the code base as well.
|
| Probably the closest things to that are test writer, technical
| documenter and build engineer.
| orblivion wrote:
| Yeah I don't think being on a team of people doing regular
| cleanups would really work well. I'm thinking more like "Oh,
| yeah we've had _that_ code hanging around for a while. We don
| 't really want to touch it because it's kind of a mess and we
| forgot how it works, but we have to make changes now and
| again. If someone could clean it up we'd be a lot more
| efficient".
|
| This would likely not even be a software company as such.
| ta94455 wrote:
| Maybe try an operations teams at a <200-300 employee company?
| Been on a few platform operations teams/systems operations teams
| where most people are working in yaml or one-off cli tools. Those
| teams are usually a mix of people who can code and can't. If you
| can code you get a lot of freedom to work on whatever you want
| without sprints/strict design docs/required tests. Just need to
| make sure a potential team has enough people that not everyone is
| fire fighting all the time. Pay is good at the right company.
| carl_sandland wrote:
| I empathize and completely agree; I like the distinction made
| between programming and 'software engineering'; the latter is all
| pure fantasy driven by the profit motive. I think we've been too
| nice to capitalists and need to reclaim our hobby from the evil.
| I'd so like to work in a well organized coop of some sort, on
| interesting challenges, damn the profit motive.
|
| And agile can go burn in hell, however 'correct' you are doing
| it.
| pc2g4d wrote:
| Tell me more about this coop...
| carl_sandland wrote:
| I think I may mean open-source, which is not really a coop. I
| guess a small start-up with like minded people is pretty damn
| identical. The coop part implies the lack of a profit motive
| though; just smart people solving problems with non-economic
| outcomes (merit).
| TrispusAttucks wrote:
| This resonates with me. If I had to sum it up.
|
| I just want to build cool shit that solves problems. It's fun.
| alexfromapex wrote:
| I just hate the interview process and working with antisocial
| teammates, love everything about the field
| 0xmarcin wrote:
| Software engineering vs programming? Sounds to me like work vs
| hobby dilemma. I love programming but I hate doing documentation,
| non-conclusive/watered-down meetings, seeking consensus with 10+
| people and scrum master "friendly advice". Nevertheless I am
| doing that because I _got paid_.
|
| As other people suggested you may consider switching to a green
| field project. Usually when there is a new product to write, you
| don't have a legacy code baggage and business is usually pushing
| for fast delivery and iteration. There is a lot of freedom, as
| long as you can deliver a working solution. Startup would be a
| good choice about 3 years ago, today I would advise to be more
| careful when changing jobs now.
| that_guy_iain wrote:
| I hate IT. I hate dealing with many developers in a professional
| setting. They're too busy trying to look good and move up a
| ladder. A lot also don't even really want to do actual work. If
| there are two solutions and one is clearly superior but a bit
| harder to do most people want to wimp out and do the easy
| solution and deal with a bunch of pain for 6 months that could
| have been avoided if they spent an extra 2 weeks doing the
| original development work.
| JohnBooty wrote:
| I hate dealing with many developers in a professional
| setting. They're too busy trying to look good and move
| up a ladder.
|
| Sometimes too true, in my experience. A lot
| also don't even really want to do actual work. If
| there are two solutions and one is clearly superior
| but a bit harder to do most people want to wimp out
| and do the easy solution and deal with a bunch of pain
| for 6 months that could have been avoided if they spent
| an extra 2 weeks doing the original development work.
|
| This was surprising to read. Generally I feel like engineers
| _want_ to do the right thing, but are pressured into short term
| kludges by management.
|
| (I don't necessarily think this means management is bad.
| Software engineering is always a balance between "do the right
| thing even if it takes much longer initially" and "actually
| ship code in a reasonable timeframe so we don't go out of
| business." You need advocates for both approaches and hopefully
| the culture is healthy enough for a happy medium to be found)
| that_guy_iain wrote:
| > This was surprising to read. Generally I feel like
| engineers want to do the right thing, but are pressured into
| short term kludges by management.
|
| I would say many of the time engineers don't want to do
| something it's a better solution but they'll claim some
| technical reason why their way is better.
|
| A good example of this is, I was working on a geo search api
| endpoint that had to work with the TPEG specs. The system was
| powered by AWS Lambda, which can scale, Elasticsearch which
| can scale, redis which can scale, etc. The system couldn't
| scale. It fell on it's ass at 500 requests per second. The
| part that fell on it's ass was Elasticsearch. Realistically,
| at 500 reads per second you know it's not really
| elasticsearch's fault but a data model problem. These are
| literally excuses that were given:
|
| * "We shouldn't do those kinds of searches because they don't
| scale." - We were contractually obligated to do this search
| with a 2 million eur penalty fee if we didn't.
|
| * "The issue is we're returning too much data" - We weren't
| having timeout issue, we were having issues with running out
| of CPU.
|
| * "We should hire an elasticsearch consultant to solve it" -
| We should be able to make Elasticsearch go more than 1% of
| it's benchmarks. Which when Elasticsearch's benchmarks were
| brought up "Benchmark's are designed in a certain way to
| scale" - Which is true when you're getting 20k and they're
| getting 30k. But when you get 500 and they get 50k - yea that
| isn't standing up.
|
| * "The scale is too much. We'll need to serve millions of
| requests per second at their highest scale. And no one can do
| that." - Basically, trying to bamboozle non techies, mixing
| up database reads with end user requests. It's literally so
| easy with Elasticsearch you can't even find a blog post on it
| because it's not worth bragging about. YOu can find people
| talking about 1 million writes per second tho.
|
| The problem was ignored until the point we almost got sued
| and looked really bad to our biggest customer. This caused
| all sorts of issues for everyone. All because they didn't
| want to do the hardwork of figuring out how to build a data
| model that can scale easily. They ened up spending 30k a
| month on elasticsearch clusters from AWS to get 500 requests
| per second. They needed something like 196 CPUS and
| terrabytes of RAM to serve 500 requests per second of data
| that was 2-3MB RAW but 150 KB compressed. While on the
| surface it could appear like they wanted to do a good job,
| the reality was this was one of many areas that were too
| difficult for them to deal with so they didn't want to solve
| it. And people will say that's just a bad team, I've seen
| that repeatedly. People shy away from the hard to do things.
| JohnBooty wrote:
| That was an interesting story to read.
|
| I would say it sounds more like "they didn't have the
| chops/experience to do it" and less like "they didn't want
| to do it?"
|
| In situations like that my instinct as a developer is to
| figure out the hard part first. Some sort of prototype to
| prove that _hey, this design works and can serve X requests
| per second._ In other words some basic prototyping and
| research... a "spike" in scrum/agile terms.
|
| Managers have viewed this as insanity. They think
| optimization is something you can sprinkle on later.
| Surprisingly a lot of developers do too.
|
| I've been on two projects where this situation happened. In
| one I was able to save the project. In the other I wasn't.
| ohcmon wrote:
| How come refactoring is not fun??
| brailsafe wrote:
| Absolutely.
| adulion wrote:
| Scaling things- i love hacking away at my own ideas and my own
| little projects that only I will use.
|
| The requirements to make things scale- Being part of a team with
| procedures and processes kills the fun for me.
| wackycat wrote:
| Honestly, I might recommend looking for an entry level job in an
| industry outside of software that has somewhat struggled to keep
| up with the changing times. Find a company where people are
| manually transferring data from one spreadsheet to another, or
| where there is a huge backlog of data in need of processing with
| some manual step that can be automated. Write one-off scripts
| that will seem like magic.
| jerjerjer wrote:
| Why would you want to work outside of a company's core
| competence?
|
| Ideally, your core competency (programming) and a company's
| core business (software development) are identical or at least
| heavily aligned. This arrangement allows you to grow your
| competency since business core competencies can be very, very
| advanced.
|
| Want to go deeper into code optimization and high performance?
| There is probably a critical piece of software in dire need of
| optimization. Want to draw diagrams? Some legacy systems need
| integration and solution architect's touch.
|
| On the other hand, working at a company where your role is
| unaligned with the core competency, you usually hit the ceiling
| on the complexity of what's required from you pretty fast.
| Sure, there are a thousand different excel files in dire need
| of wrangling, but you are really hitting diminishing returns on
| your skill building after the hundredth one.
| amackera wrote:
| Not everything in life has to be "fun". Sometimes important
| things aren't fun to do, but we do them because they are
| important.
|
| Seeking endless fun is vain and meaningless. Doing meaningful
| work requires discipline and perseverance, it won't always be fun
| but it'll be more satisfying.
| markhahn wrote:
| SE should be one of those "if it's not fun, you're doing it
| wrong" things no?
|
| alternatively, consider that it's just a minor component of
| programming in general: it doesn't deserve to be called a field:
| just like "using sandpaper" is just one of many activities within
| the profession of carpentry.
|
| we do SE in order to program.
| mch82 wrote:
| Analyst
|
| Researcher
|
| Artist
|
| _Analyst_ meaning a person who works with something like Jupyter
| Notebooks or VBA in Excel to do non-recurring work. _Researcher_
| meaning an academic or corporate researcher who tries experiments
| in code to prove our concepts. _Artist_ meaning a person making
| fun things like art, cosplay, entertainment, games that can't
| hurt people and don't need high reliability.
| duringwork12 wrote:
| yes
| newbieuser wrote:
| all of the things you listed are included in the software. and
| they all serve the same thing. to maintain the software. you
| should focus on the purpose as much as you focus on the process.
| Aeolun wrote:
| Huh, I find that I like a lot of the things that you hate.
| Refactoring and rewriting can be tedious, but it's a hundred
| times more fulfilling than fixing bug #39004.
| brailsafe wrote:
| Yep. I'm sure there are comlabies out there that don't suck, but
| I haven't found them yet.
| dajonker wrote:
| I co-founded a company as the only software developer and it's
| the most fun I've ever had building software. That includes all
| the refactoring, architecting and rewriting. What's important in
| my case is that I have awesome co-founders who have completely
| different roles and skills and that trust me to deliver the tech.
| We don't have investors, only our own money on the line. We also
| don't have any recurring meetings, communication is mostly async
| and that works great for developing software. There is a vision
| and a rough roadmap but we don't do any short term planning, that
| would be a giant waste of time. We just had a very successful
| first year!
|
| The job is not without any hard parts though. I may have a lot of
| freedom to build a product the way I want, but I didn't have any
| technical colleagues to discuss problems (or joke around) with. A
| start-up naturally comes with a lot of uncertainty. You have to
| make a lot of hard decisions and then make sure they were the
| right ones. And it might take some time before I make as much
| money as I did working for someone else.
|
| Every job will have pros and cons and you'll always need to make
| some trade offs.
| t43562 wrote:
| If you ever do need to take on other people when you get
| overwhelmed then you'll end up having to develop patterns of
| behavior even if you don't call them processes. There might
| even be a point where you cannot keep up with all of it - that
| is a freaky feeling. Then you're trying to keep things working
| without being able to understand to the last detail what
| everyone is doing.
|
| Your codebase might be tending towards a pile of crap or not
| and you'll have to try to make it not by asking people to do
| code reviews or tests.
| PixelForg wrote:
| As a junior software engineer, I think the same but perhaps I
| have come to the conclusion too early. What I know is that I want
| work to always be easy or maybe with slight difficulty, and keep
| the hard stuff for personal projects. That way I wouldn't feel
| much stress.
| tabtab wrote:
| Yes! Web stacks have grown too convoluted and round-about. I used
| to do what's now called "full stack development" for small and
| medium applications. But that's almost impossible to do well and
| efficiently because web stacks shot YAGNI and KISS bloody dead.
| It now often takes layer specialist to do it well. Some say we
| have to burn what desktop IDE's did well to get HTTP-based apps,
| but I haven't seen any solid proof they are mutually exclusive.
| It just needs more R&D.
|
| We need new web UI standards that are CRUD-friendly. Social media
| and e-commerce have been wagging the web UI dog, but CRUD
| matters: it's not sexy, but runs the world. Standards
| improvements or addition possibilities include a state-ful GUI
| markup language (sort of like the best of YAML, XUL, & QML),
| and/or do something like Java Applets correctly, learning from
| security and version/package-management mistakes of the past.
|
| Similar opinion:
| https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_goi...
| VoodooJuJu wrote:
| I hate both programming and software engineering, but I love
| money, flexible work schedules, and no risk of falling off a roof
| while on the job.
| collyw wrote:
| I actually enjoy the parts you don't seem to - architecture,
| refactoring, designeding systems from teh ground up is what I
| really enjoy. Debugging - my own code, fair enough, that's my
| responsibility, when it's other people badly written code, not so
| much. Sprint and agile is meh, but I guess you need a way of
| organizing a team. uess I like focusing on the large scale parts
| of the problem, while you seem to prefer the small scale parts.
| Maybe we wwould make a good team.
| subharmonicon wrote:
| I've always enjoyed "programming in the small" more than
| "programming in the large", especially when the latter is in a
| position where I am part of a huge machine shipping a huge
| product to a large number of users, which has been most of my
| career.
| zelphirkalt wrote:
| If writing tests is fun for you, you could theoretically accept a
| position that is writing tests and fixing bugs all day long. Pay
| is a question of course.
| loup-vaillant wrote:
| > _I 'd rather get to value now by making something that just
| works(and is adequately tested) than engineer something thats
| future proof but takes longer to get out._
|
| If you haven't read it, I highly recommend _A Philosophy of
| Software Design_ by John Ousterhout. His talk is a great teaser
| for the book: https://www.youtube.com/watch?v=bmSAYlu0NcY
|
| Here's the thing: a program properly written for the future does
| _not_ take longer to get out. Not much, at least. What we
| instinctively think of as "future proof" is generally anything
| but: by anticipating some particular kind of change that may
| happen some time in the future, but in practice almost never
| does, we end up with more complex programs that are _harder_ to
| modify when an actual (typically _unforeseen_ ) change comes our
| way.
|
| The best way to future proof your program is to make it _simpler_
| , according to the requirement you are _currently_ aware of. If
| you expect a particular change, sure, plan for it. But for the
| unexpected, just keep it simple. Because simple is easier to
| adapt, add to, or rewrite.
|
| That said, the simplest solution is rarely the most obvious.
| Making thing simple does take a bit more time than rushing
| through the first thing that comes to mind. But it also pays off
| in a matter of weeks, so it's quite worth it.
|
| And if you have a hard time assessing what "simple" means, SLoC
| is a surprisingly good metric (we have research that shows this).
| And mostly your modules should be deep: small APIs that hide
| significant implementations. I think of it as encapsulation on
| steroids.
| usermame wrote:
| Play store tirar todos os dias gigantes
|
| 99999999999999999999999999999999999999999999999999999999999999999
| 99999999999999999999999999999999999999999999999999999999999999999
| 99999999999999999999999999999999999999999099999999999999999999999
| 9
| patrec wrote:
| > Finding and fixing bugs is a lot of fun. Incidence response is
| a lot of fun. > What are some good jobs for a person like this?
|
| SRE/Devops person at a FAANG.
| proc0 wrote:
| I strongly dislike enterprise development/engineering, but I love
| programming/engineering. Enterprise software is written to
| optimize for the most amount of people working on any given
| codebase. As a result the practices and conventions adopted tend
| to sacrifice many programming techniques that would otherwise
| prevent a number of recurring problems.
|
| This is also why pure functional programming never takes off
| despite being the more advanced and sophisticated way that
| leverages techniques which would prevent bugs and speed up
| development. I understand why large companies prefer extremely
| verbose, repetitive code, which allows for easy scaling of
| engineers, but I wonder what the industry could be if engineers
| prioritized computer science - more robust codebases, faster
| development which would translate to better products that never
| break while at the same time evolve faster.
|
| "Planned obsolescence" might make business sense for hardware,
| but I feel software has so much wasted potential at the moment.
| 29athrowaway wrote:
| You can try
|
| - Education
|
| - Tech evangelism
| H4ZB7 wrote:
| [dead]
| bhargav wrote:
| Do you actually just like programming and hate "engineering" side
| of things?
|
| What if you just did programming but we're told how to program?
|
| Sometimes people get burned by processes and sometimes people
| just don't want others opinion and want to do their own way in
| their own world.
|
| I honestly go through ebbs and flows between the two and honestly
| I think a good middle ground is some process. I've learned a lot
| (and literally did just yesterday from an RFD review) so I can't
| dismiss process altogether.
|
| If I want more autonomy I'd work at a smaller company. I do miss
| the days of my old company where I wrote so much of the system.
| From payments to auth to order and fulfillment. It was fun, and I
| knew everyone in the company. Thinking more about it writing this
| just now though, I think my code would've been better with more
| reviewers nudging in the design process.
|
| You might want to consider doing some open source hobby work as
| well btw; I am doing that rn.
| pitched wrote:
| Engineering (and Software Engineering) is all about building a
| bridge that barely stands. Tuning the entire process to be cheap
| as possible with as little risk as can be stomached. It's very
| concerned with what happened in the past, to feed into those
| decisions.
|
| Science (and Computer Science) is all about getting a giant
| telescope into space. Tuning the entire process to discover and
| keep working when it finds some new and unexpected. It's very
| concerned with what might happen in the future, and uses those
| predictions to feed into current decisions.
|
| It sounds to me like you've got it backwards. It's the science
| you don't much enjoy. Maybe try your hand at something like
| project management to get closer to the engineering role?
| Decabytes wrote:
| One thing I've realized is that a lot of people I know don't
| actually like programming or software engineering in general. A
| lot of my coworkers just do it because it's the tool they need to
| do their job (like using a hammer). It's tough because I love
| programming and geeking out about it, but it feels like no one
| around me feels the same way
| rewgs wrote:
| I feel the same way. All my programmer friends have all said a
| version of the refrain, "I just work hard for 8 hours then
| check out. I don't care about programming beyond what it will
| pay me." I understand and of course don't fault anyone for that
| point of view, but it'd be nice to be around people who
| actually get excited about this stuff.
| deostroll wrote:
| The fun part is mainly dependent on the leaders and culture. If
| they are serious about agile then you finally fit/assimilate into
| that work style. But without opportunities to communicate, like
| for e.g. constructively discuss or debate, things will start to
| appear stale. That is where I think the excitement takes a
| plunge.
| jagtstronaut wrote:
| I feel this, but maybe a little different. I love programming,
| but I don't love all the framework stuff that you end up
| constantly managing in a more mature app or the initial set up of
| all the dependency stuff overwhelms me.
|
| Figuring out why some cloud formation stack BS isn't working just
| isn't fun to me. I prefer the kind of work where I can solve the
| problem by surfing through the actual code and figuring it out.
| JSavageOne wrote:
| This is why I work at startups.
| jantypas wrote:
| Perhaps you don't enjoy working for a software engineering
| _organization_. When the organization is concerned about
| methodology as opposed to getting the result, that can be a
| problem. Too often, I 've been in organizations that found a new
| trend but never asked if it actually mattered. That being said,
| methodology does matter. We've all been around someone who just
| threw something together, it was _our_ job to clean up the mess
| :-)
| PragmaticPulp wrote:
| > I have come to a realization that I don't really enjoy Software
| Engineering(& the processes that it comes with) but I do love
| programming & solving problems.
|
| I can almost guarantee that you're just at the wrong company.
|
| Some software companies can turn even the simplest tasks into a
| grueling series of processes, endless meetings, and joint work
| across a big number of "stakeholders". These companies will take
| the joy and productivity out of programming and replace it with a
| series of rituals and set of language that people use to go
| through the motions every week so they can collect paychecks.
|
| Start interviewing around. Talk to your network. Find a company
| that values programming and real productivity but discourages
| unnecessary meetings and process. You will be much happier. There
| is no escaping the fact that you'll have to work on legacy code,
| document your work, and meet with people some times. However, it
| doesn't have to be a miserable process-filled slog.
| kraig911 wrote:
| 1000x times this. It's a weird thing our profession. There's a
| horrible but apt (misogynistic even) saying. Happily married
| men are happy husbands - Unhappily married men are great
| philosophers. I really feel agile has killed the happiness of
| our industry because it's met with a lot of back and forth,
| meetings, rituals, and meta-work and not actual productivity
| (If agile is done well though it can be amazing but that's
| another topic to me)
| onehair wrote:
| Would the opposite of what you describe here be : program all
| the time and ship things as fast as possible?
|
| I've found that in many cases, that generally makes return on
| investment hard to keep track of, and I think that most
| companies want profit. Balance is the key though and
| balancing what you describe as bad with fast shipping, I
| think is the best of both worlds
| jasmer wrote:
| It's 'gendered', not 'misogynist'.
| jacobr1 wrote:
| > I really feel agile has killed the happiness of our
| industry
|
| Waterfall had its own endless set of meetings and downsides.
| I'm not sure agile changed that at all in the large,
| regardless of how "well" agile was implemented. Some teams
| did have project management that "shielded" teams, but that
| can happen under agile too, depending upon how it is
| structured.
| t43562 wrote:
| I've enjoyed it working well. It was much better than being
| project managed. A great deal of the time it let us toss
| out stupid requirements - they just sat at the bottom of
| the infinite backlog because they weren't needed yet.
| necovek wrote:
| It's actually quite funny because "agile" basically means (in
| English) "quick to react", which should imply not much
| process at all (and when properly implemented, usually is).
| wpietri wrote:
| > agile has killed the happiness of our industry
|
| I don't think you're wrong, but I should point out that Agile
| started out as a rebellion against "meetings, rituals, and
| meta-work and not actual productivity". As somebody who got
| involved in one of the Agile tributaries before the term
| "Agile" was coined, I'd say the actual problem is older and
| deeper.
|
| I look forward to another rebellion, but would-be
| revolutionaries should make sure they don't fall into the
| same trap, or you too will see your new terms and bold ideas
| corrupted to the point of meaninglessness.
| ianmcgowan wrote:
| It seems that this generation's revolutionaries are always
| the next generation's reactionaries..
| wpietri wrote:
| In this case, not so much. Most of the early Agile people
| I've had the chance to talk with are a bit horrified by
| what it's become.
| 59nadir wrote:
| Indeed. Most of the commentary I've seen from people who
| were around is that scrum isn't agile but just an
| impotent compromise made by people who thought business
| could never actually handle an actually agile (as in
| flexible) work methodology. I think they're mostly right;
| Scrum really isn't very flexible.
|
| On top of that, like most popular languages and
| technologies it isn't really good enough for people who
| care, but it's good enough for people who don't and also
| happens to please "biz" people.
| wpietri wrote:
| Totally agreed! And "good enough for people who don't
| [care]" is exactly it. Mainstream adopters for anything
| don't want big improvements if they have to change:
| https://williampietri.com/writing/2011/agiles-second-
| chasm-a...
| fijiaarone wrote:
| Isn't that the definition of reactionary?
| wpietri wrote:
| No? Reactionaries want to return to the previous status
| quo. The early Agile people I know instead would like to
| see a revolution actually happen.
| highwaylights wrote:
| I'm with you right up to "if agile is done well".
|
| It's just a buzzword for practices that people would be doing
| better otherwise without all the bureaucracy. Pretty sure one
| of the original authors of the manifesto declared it dead
| too, but I'm not going to google it because honestly the
| agile manifesto is not a religious text to me and I think the
| whole industry grew out of a single fairly common sense idea
| that got utterly co-opted by snake oil salesmen.
|
| Like DevOps.
| mindcrime wrote:
| It's a fair point. The whole DevOps thing is so ludicrous.
| I've seen companies that don't just have a "DevOps team"
| (which is absurd in and of itself) but _multiple_ DevOps
| Teams, and I 'm pretty sure there are some DevOps Teams
| that have embedded DevOps Teams that in turn have more
| embedded DevOps Teams.
|
| And _all_ of these people are completely gated off from
| interacting with the people actually building applications
| by a byzantine process involving ServiceNow tickets, MS
| Teams messages, eldritch incantations to Elder gods, ritual
| sacrifices, and the phrase "The goat doesn't need to be
| very big, but it does need to be alive."
| Aeolun wrote:
| I think you are underestimating the DevOps teams.
|
| Cthulhu is a lot easier to please.
| garethrowlands wrote:
| DevOps merges Dev and Ops. It is not an extra team.
| mindcrime wrote:
| Sure, you and I know that. But try telling that to all of
| these companies out here standing up a "devops team" left
| and right!
| tjrDL6MjB2Zwwa wrote:
| > Happily married men are happy husbands - Unhappily married
| men are great philosophers.
|
| I'm not sure I understand what this means, can someone
| clarify for me?
| rerdavies wrote:
| Philosophy is for unhappy people.
| tjrDL6MjB2Zwwa wrote:
| [flagged]
| alexvoda wrote:
| I have detailed that and linked an even more comprehensive
| explanation in this sibling (cousin?) comment:
|
| https://news.ycombinator.com/item?id=34380697
| tjrDL6MjB2Zwwa wrote:
| [flagged]
| fijiaarone wrote:
| You'll have to get married and grow old to understand.
| tjrDL6MjB2Zwwa wrote:
| [flagged]
| mpweiher wrote:
| > agile has killed the happiness...meetings...rituals...meta-
| work...not actual productivity.
|
| All of that isn't actual agile. It's Fauxgile and has nothing
| to do with what agile is about, which is about removing
| impediments to productivity, removing meetings (why were
| there standups? Because they shouldn't exist in the first
| place, and if you absolutely positively can't avoid them then
| at least make them as short as possible by making everyone as
| uncomfortable as they should be) and laser-focusing on actual
| productivity.
|
| > (If agile is done well though it can be amazing but that's
| another topic to me)
|
| Yes. I would phrase it as: if agile is actually done.
| thwawawa1234 wrote:
| Agile is made up. The vast majority of places "do it
| wrong". Coaches come in and make things even worse, with
| even less understanding. Saying "they are doing it wrong"
| and having nothing change isn't doing anything, and it's
| not really a great point. (Not specifically calling you out
| I just hear this all the time)
|
| "Fauxagile" *is* agile, because thats what the majority of
| places in reality do.
|
| "Agile" needs a complete rebrand.
| goodpoint wrote:
| "Agile" needs to stop existing.
| MiyamotoAkira wrote:
| Rebranding wouldn't help. The same people doing Fauxagile
| will be doing FauxX after. The underlying issues of why
| Fauxagile exists don't get removed because of rebranding
| JakeAl wrote:
| Agile just means making it up as you go when you have
| people who don't have the knowledge or experience to
| define first exactly what is required. If more
| programmers became managers and could work with the
| stakeholders, most specifically the clients that are
| ultimately paying their salaries then there would be
| fewer problems with waterfall. My experience is that if
| programmers would read the design document written by
| people who are knowledgeable instead of wanting to build
| it on the fly there would be no need for agile (assuming
| experienced people are writing the design documents.
| After ~1998-2000 it seems like marketing and sales were
| the ones that ended up doing that despite having no
| education or experience in designing software interfaces
| let alone programming). But that's just my experience,
| and I learned early on the first thing you do is read the
| manual and if it doesn't answer all the questions then
| ask and re-write the manual yourself before doing any
| budgeting or coding. Instead we got agile, which turned
| into make it up as you go through constant
| sprints/iterations and meetings as you design and build
| it rather than on paper. As comic Dave Smith said, if you
| say it works on paper but doesn't in practice then it
| doesn't work on paper either.
| t43562 wrote:
| Usually you know the least at the start so your plans at
| that point are rubbish. So you keep refining your plans
| .....
|
| Who gets to do things that they have experience in all
| the time? Not me at lest. And what manual do you read ?
| There's almost never anyone who understands it all quite
| apart from having written "a manual".
| madeofpalk wrote:
| Productive teams understand that any "way of working" is
| just a means to an end, and that good teams find a way to
| work that suits them (and their situation).
| ajmurmann wrote:
| "Individuals and interactions over processes and tools"
| as the Agile Manifesto would call it. Quite different
| from having a certified scrum master
| fijiaarone wrote:
| Certified Scrum Masters are individuals who need jobs.
| mindcrime wrote:
| Can't upvote this enough times. Time and time again you see
| this: people say "I hate agile because of X, Y and Z" where
| X, Y, and Z - _at best_ - are orthogonal to the idea of
| Agile, and at worst (and perhaps even "ordinarily") are
| complete anathema to the spirit of Agile.
|
| Sorry, but anybody who thinks Agile is about velocity,
| story points, planning poker, standups, retrospectives,
| backlog grooming, etc. has been sold a bill of goods. Now
| that's not to say that those things don't have (some)
| value. But they aren't "the thing" about Agile. Not even
| close.
| selestify wrote:
| What is actually Agile then, and how does one actually
| practice it?
| Viliam1234 wrote:
| You asked about Agile, but I will talk about Scrum
| instead, because I am more familiar with it.
|
| https://scrumguides.org/scrum-guide.html
|
| Ctrl+F "JIRA" - 0 results
|
| Ctrl+F "velocity" - 0 results
|
| Ctrl+F "on-call" - 0 results
|
| Ctrl+F "manager" - 0 results
|
| Selected quotes:
|
| > Scrum Teams are cross-functional, meaning the members
| have all the skills necessary to create value each
| Sprint. They are also self-managing, meaning they
| internally decide who does what, when, and how.
|
| > During the Sprint: No changes are made that would
| endanger the Sprint Goal;
|
| > The Daily Scrum is a 15-minute event
|
| A short version is that you have a small team of
| intelligent people who are given sufficient autonomy.
| They split time into intervals called "sprints", each
| sprint is 2-4 weeks long. (If you have no experience with
| Scrum, start with 2 weeks. When you get used to it, the
| team can decide the correct length.)
|
| At the beginning of the sprint, the developers and the
| representative of the customer agree what gets done.
| During the sprint, the developers do it. Every day there
| is a short meeting in the morning, when developers say "I
| completed this; I am going to work on this; I am blocked
| by this", nothing more.
|
| At the end of the sprint, developers show the implemented
| changes to the representative of the customer. Then the
| developers talk among themselves about what was good
| during this sprint, what was bad, and what they want to
| do differently the next time.
|
| The important thing (ignored at almost all companies
| pretending to do Scrum) is that in this ideal world,
| managers do not exist. Developers manage themselves. In
| the daily meetings, developers report their progress to
| each other. What needs to be done, is decided by the
| representative of the customer (literally a person from a
| different company, or from a different department if this
| is an internal project). How it gets done, that is
| decided by the developers. When developers talk about
| what was good and bad, and what needs to be done
| differently, they actually have the power to do it
| differently the next time. Developers assign the work
| between themselves, and make estimates how long something
| would take.
|
| Shortly: the developers are treated as adults, and their
| responsibility to the customer is defined on a biweekly
| or monthly basis.
| gonzo41 wrote:
| You speak with a client. They say what they want. You
| build it they test it, and state objections and or
| request more features. You discuss and then build the
| agreed thing. And then you do this loop untill you ship
| Too wrote:
| The whole idea is that there is no strictly formal
| version of the process. It can't be answered with a
| package. The process itself is agile, ammendable, fluid,
| mutable, improvable. You do what works for you.
|
| Just stick to the principles of focusing on the product
| customer value over the processes themselves, with
| recurring reflection over how your process is working, as
| per the agile manifesto.
|
| If your company hasn't done this before, Scrum is a good
| starting point, but it is by no means a goal nor the
| final destination. This is where most companies fail.
| fabioborellini wrote:
| Some companies will just request a ready-made agile
| process from a certified agile overlord. The process will
| hinder productivity since only reporting parts and
| rituals are implemented, and all improvements suggested
| by individuals participating are dismissed since they are
| "against the agile process".
|
| I did leave and the company did crumble shortly
| afterwards. The main reason wasn't related to processes,
| though. It was already too late when the faux-agile was
| introduced.
| cwingrav wrote:
| Agile is to Lenin as Agile processes are to Stalin.
|
| Read the Agile Manifesto. That's what Agile is. All else
| is either: - (good) trying to implement the Agile
| Manifesto, or - (bad) trying to make current process
| appear like Agile.
| ajmurmann wrote:
| agilemanifesto.org
|
| Constant reflection and drive towards faster feedback. XP
| or if I squint Scrum can be a starting point, but you
| gotta adapt to the individuals on the team and the
| characteristics of the type of problem you are solving.
| lr4444lr wrote:
| It's a methodology that makes software more resilient to
| the changing needs of the business. Anything that
| violates the 12 canonical principles[0] should be thrown
| out - and this has to be determined by each org.
| individually.
|
| [0] https://agilemanifesto.org/principles.html
| mindcrime wrote:
| /u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just
| what the Agile Manifesto says. Strictly speaking, "Agile"
| in and of itself isn't even a methodology - it's just a
| set of principles, to which a number of concrete
| methodologies claim some association. They differ in the
| degree to which they faithfully represent the spirit of
| the manifesto.
|
| So really, you're never "doing Agile". You're "doing $X"
| where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or
| whatever. At most companies what you get, in my
| experience, is a bastardized version of Scrum cobbled
| together by somebody who has never actually developed
| software, took a couple of Scrum classes (maybe), paid
| too much money for some "help" from some "Agile coaches",
| and is hoping some of the resulting shit will stick to
| the wall.
|
| FWIW, I've actually had the pleasure of working at
| company that did Scrum and really did it well, and it was
| honestly a great experience. Actual Scrum, as documented
| in the Scrum Guide, isn't bad. The problem is when people
| take base Scrum and start tacking on additional shit
| (see: "agile coaches" and "agile consultants") and wind
| up with a bureaucratic / kafka-esque tarpit of
| interminable meetings, ceremonies, and artifacts. In
| other words, pretty much _exactly_ what the Agile
| Manifesto stood against in the first place.
| RHSman2 wrote:
| Difference between doing Agile and being agile is the
| same as education. You can have engineers who are
| educated well and you can have engineers who get stuff
| done, well without a high level of 'education'.
| ttyprintk wrote:
| You're talking about training, not education. A masters
| in engineering will be an experience in software
| architecture. An engineering role under one of these
| management styles will be an experience in training.
| RHSman2 wrote:
| No I'm not. You are.
| lelanthran wrote:
| > Sorry, but anybody who thinks Agile is about velocity,
| story points, planning poker, standups, retrospectives,
| backlog grooming, etc. has been sold a bill of goods. Now
| that's not to say that those things don't have (some)
| value.
|
| Spot on. You and parent have hit the two points that
| matter:
|
| 1. Agile is about removing impediments to productivity
|
| 2. velocity, story points, planning poker, standups,
| retrospectives, backlog grooming, etc are all, in some
| way, impediments to productivity (even if they do have
| some value).
|
| I think the real reason you cannot have _real_ agile is
| because businesses don 't run in a way that is compatible
| with agile, so over time all processes within a business
| will evolve to match how the business itself functions.
| mindcrime wrote:
| _I think the real reason you cannot have real agile is
| because businesses don 't run in a way that is compatible
| with agile, so over time all processes within a business
| will evolve to match how the business itself functions._
|
| Sadly, I think you are correct. It's very hard, at best,
| to make "the business" operate in a way that's truly
| compatible with the agile approach on the tech side. :-(
|
| I won't say it's _impossible_ , but it's definitely not
| easy.
| garethrowlands wrote:
| Strong agree.
|
| Except it's not even really about productivity, it's
| about outcomes. The productivity is only important
| insofar as it achieves the outcomes. The ideal agile
| process would have the team on the golf course or in the
| spa but still changing the world (any suggestions on
| achieving this, gratefully accepted, as always).
| t43562 wrote:
| Yes, the business leadership almost always put an
| impossible waterfall approach ontop - they don't adapt to
| change at all well and are not really leading.
|
| For me the value in Agile is what we end up NOT doing -
| we never get to that shit because in the end it's not
| that important. So we never waste time doing it.
| peteradio wrote:
| But if you are joining an Agile shop what do you get on
| average?
| mpweiher wrote:
| Fauxgile.
| roundandround wrote:
| And every time communism meets the real world we call the
| required modifications state capitalism.
| lazyasciiart wrote:
| I thought it was called the welfare state, or social
| democracy.
| ajmurmann wrote:
| Scrum
| fijiaarone wrote:
| Jira
| barrenko wrote:
| Agile is like socialism at times.
| t43562 wrote:
| Well, you probably like paid time off (as American
| companies like to call it) and that's a socialist thing.
| Potentially you might enjoy free healthcare if you could
| get it - at least you get free policing and defense.
|
| Which country implements pure capitalism? What would that
| even look like? 0 tax? having to pay private police
| companies? ....
| [deleted]
| dismalpedigree wrote:
| Agile is like capitalism at times.
| maerF0x0 wrote:
| > Yes. I would phrase it as: if agile is actually done.
|
| Agile was the best of times, Agile was the worst of
| times, Agile was the age of wisdom, Agile was the age of
| foolishness, Agile was the epoch of belief, Agile was the
| epoch of incredulity, Agile was the season of light,
| Agile was the season of darkness, Agile was the spring of
| hope, Agile was the winter of despair. -- Paraphrasing
| Charles Dickens
| fijiaarone wrote:
| Except socialism demands rigid control.
| LAC-Tech wrote:
| Bad idea in the first place, and when implemented
| horrifying beyond belief?
| drewcoo wrote:
| I can't tell whether that's supposed to be upper-case or
| lower-case agile.
| gonzo41 wrote:
| Big A agiles is more like capitalism. Tricking the plebs
| into working to the bone for a promise that never
| materialises
| RussianCow wrote:
| I'm not sure what this means.
| flyingfences wrote:
| "'Real' socialism hasn't been tried, so you can't say it
| doesn't work."
| int_19h wrote:
| It has been tried, though, and it works fine in e.g.
| Chiapas. Granted, that's not an industrialized and mostly
| urban society, but not everything has to be one.
| madeofpalk wrote:
| Exactly!
| SoylentYellow wrote:
| Socialism has a somewhat agreed upon base set of
| principles and comes in a thousand different flavors, but
| at the end of the day every large scale attempt has ended
| up with an authoritarian state and either failed or
| converted to Capitalism. So whenever you say Socialism is
| a failure, you end up hearing "Well THAT wasn't really
| Socialism!" Same with Agile.
| LAC-Tech wrote:
| I've read the original manifesto and principles, and quite
| frankly I'm not that impressed with them either.
|
| Some of the principles are actively harmful, like welcoming
| changing requirements late in the process.
| SAI_Peregrinus wrote:
| Yep.
|
| "Individuals and interactions over processes and tools"
|
| OK, not terrible, but why not "interactions and tools
| over individuals and processes"? De-emphasize
| individual's egos and ritualized processes, focus on the
| things that get work done and communication between
| entities.
|
| "Working software over comprehensive documentation"
|
| Tends to make very frustrating-to-use software, because
| it's never fully working and has minimal documentation.
|
| "Customer collaboration over contract negotiation"
|
| Fine. You'll still need a contract, but it's definitely
| important have a collaborative rather than adversarial
| relationship with customers.
|
| "Responding to change over following a plan"
|
| Tends to make sense when gathering requirements, turns
| into a horrible idea later on in a project. Also fails
| utterly when working with something like a factory
| (making a hardware product with embedded software). If
| your entire view of software is web apps, this one seems
| like a good idea. If you're making something with a
| manufacturing deadline, it's a recipe for disaster.
| fijiaarone wrote:
| The Agile Manifesto starts with "We have found..."
|
| So that's the why. You can ask for elaboration, or
| disagree with the results, but the opinion of the signers
| of the Agile Manifesto, based on their experience, is
| that to prefer the former over the latter, while
| acknowledging that the latter principles have value, they
| tend to succeed (and enjoy their work more) when deciding
| between the two (there are always trade offs) to give
| greater weight to the more lightweight, practical, and
| less rigid values -- hence the use of the word "agile".
| Sohcahtoa82 wrote:
| > "Working software over comprehensive documentation"
|
| > Tends to make very frustrating-to-use software, because
| it's never fully working and has minimal documentation.
|
| Another problem:
|
| It makes onboarding new engineers difficult. Without any
| documentation on what each API endpoint does, or the
| purpose of every repo, getting an understanding of how
| the system works ends up requiring scanning through code
| manually or taking a lot of time from other engineers
| asking questions.
|
| It's especially bad when microservices are given non-
| descriptive names like Galactus or Omega Star.
| brazzy wrote:
| "over" does not mean "to the complete exclusion of".
|
| The point is that documentation by itself doesn't deliver
| any value, and there are diminishing returns with amount
| and detail level of documentation.
|
| Agile doesn't say you shouldn't document, it says you
| shouldn't spend more time documenting your API endpoints
| than Implementing them.
| t43562 wrote:
| Rather have a big document for a program that doesn't
| work?
| Dudeman112 wrote:
| Yes
|
| You can get there with a big document for a program that
| doesn't work
|
| You can't get anywhere with a program that works and no
| document. You might get sales, but that's someone else's
| job
|
| I certainly would have preferred just a big document
| instead of the code I was given on my current role
| t43562 wrote:
| I meant: you'd be happy to hand your stakeholder a
| document about the code you would have written if you'd
| had time to?
| Aeolun wrote:
| > Tends to make very frustrating-to-use software, because
| it's never fully working and has minimal documentation.
|
| This was written in a time when documentation/spec was
| often written before the software, without taking into
| account the difficulties of implementing it.
|
| Agile seems to imply that software comes before
| documentation in terms of priorities.
| jacobr1 wrote:
| > Working software over comprehensive documentation
|
| This means something a little different. It wasn't
| talking about "end-user" documentation. Rather, it meant
| "product specifications." Do you need to design the
| system upfront in UML before you start writing code? You
| may still need something like a whiteboard sketch or
| something similar, but that wouldn't be "comprehensive."
| seadan83 wrote:
| Keep in mind the agile manifesto authors were
| consultants, working as consultants, and the manifesto is
| largely in the context of software consultancy.
|
| A lot of the points in the manifesto turn out to be
| slightly redundant. Comprehensive documentation, as
| entered into a tool, is wasted time when what you need to
| do is spend time with the customer developing their ideas
| into good software.
| lelanthran wrote:
| > "Customer collaboration over contract negotiation"
|
| TLDR: Businesses purchase development effort in terms of
| contracts, and the contract is almost always _" You will
| deliver $X for $Y amount, in $Z months or less"_. Agile
| is the opposite of that as far as business is concerned -
| _" We will pay $A per hour until our money runs out or we
| are satisfied with what we get"_.
|
| I've never understood this one, to be honest. Business
| runs on contracts; in any interaction with the outside
| world (suppliers, customers, employees, etc) the
| businesses contract is what makes or breaks that
| interaction.
|
| In 999 out of 1000 cases, no contract == no interaction.
|
| I mean, look at it this way: when you ask a crew to paint
| your house, you specify the colors upfront. You don't
| iterate with them on after every room, or every wall.
|
| You certainly _will not_ engage with any crew who wants
| to paint your house using the guidance of the Agile
| Manifesto, because then you 'd have little to no upfront
| indication of the cost, you might have a house not gully
| painted (because you're paying per hour for their time,
| and once your money runs out they stop working).
|
| Agile works great for teams internal to the business -
| the money never runs out unless the business shuts down.
| But for external developers, the business cannot engage
| without a contract, and that contract will be _" You will
| deliver $X for $Y in $Z months"_, and not _" We will pay
| you $A hourly until we are satisfied with the result"._
|
| The practical result is that the agile way and the
| business way are entirely opposites of each other. This
| explains why dev teams within companies constantly
| complain _" This isn't Agile!"_ ... because business is
| trying to enforce some sort of _" Deliver $X within $Z
| months"_ and the agile team is working with _" We'll
| collaborate until the stakeholders are satisfied"_
| deadpannini wrote:
| > I mean, look at it this way: when you ask a crew to
| paint your house, you specify the colors upfront. You
| don't iterate with them on after every room, or every
| wall.
|
| This isn't a useful analogy - more often, it's like
| asking a crew how much it would cost and how long it
| would take to paint your house, except the house isn't
| built yet, you're not sure what you're going to use it
| for (or whether you'll actually use it as a _house_
| rather than a B &B), plus you reserve the right to change
| colors at any point in the process.
| LAC-Tech wrote:
| It's like you reached inside my head, pulled out my
| crudely formulated thoughts and feelings on why it struck
| me as ill-advised, and refined and explained everything
| perfectly.
|
| Internal teams! My work these days is directly with
| people paying for the thing. That's why Agile gives me
| the shivers.
| t43562 wrote:
| It's unfortunate that you haven't understood any of the
| problems of writing software or buying on contract
| despite having it laid out for you.
|
| In reality people change their minds - especially when
| they see the software - so there's a lot to be said for
| building it incrementally and showing it to them.
|
| The fact that contracts don't suit this behavior might
| explain why contracts are such an awful way to get
| software and why they so often go wrong.
| lelanthran wrote:
| > It's unfortunate that you haven't understood any of the
| problems of writing software or buying on contract
| despite having it laid out for you.
|
| > In reality people change their minds - especially when
| they see the software - so there's a lot to be said for
| building it incrementally and showing it to them.
|
| Doesn't matter - the people paying for the software are
| not the ones that are going to be using it, so showing it
| to them is pointless (they just want their bullet
| points/requirements checked off).
|
| Showing the software to the users is equally pointless,
| because they don't have the authority to request changes
| (any change is a bill that has to be approved).
|
| See my other reply to you: https://news.ycombinator.com/t
| hreads?id=lelanthran#34381865
|
| > The fact that contracts don't suit this behavior might
| explain why contracts are such an awful way to get
| software and why they so often go wrong.
|
| Maybe, but unless you have an alternative that addresses
| the problems in not having contracts, there's little
| point in telling other people that they don't understand
| the problem.
| rerdavies wrote:
| A good friend of mine worked for HP Consulting, which at
| the time was using heavyweight waterfall method. Out of
| curiosity, I asked her how well they hit their schedules
| and costs.
|
| "Oh, we hit our schedules and costs 100% of the time",
| she said.
|
| I was incredulous, so I pressed her on the point.
|
| "Well, compared to the contracted schedules and costs, we
| run 200% over on average by the time we deliver. But what
| happens is that customers quickly figure out that what
| they contracted for isn't anything like what they
| actually need. And every time a requirement changes, we
| add time and money. A lot of time and money. More than
| enough to make up for any actual overruns. So we always
| hit our schedules and costs exactly, by the time we're
| done."
|
| In short, "We will deliver $X for $Y amount, in $Z months
| or less" is a total scam.
| lelanthran wrote:
| > And every time a requirement changes, we add time and
| money. A lot of time and money. More than enough to make
| up for any actual overruns.
|
| ...
|
| > In short, "We will deliver $X for $Y amount, in $Z
| months or less" is a total scam.
|
| How is that a scam? _" We will deliver $X in $Y months
| for $Z money"_ is easily predictable by the client when
| the client wants to change $X.
|
| If the client doesn't change $X, the client can
| understand what they will pay and when they will get it.
|
| When the client changes $X to $X+a, _they still
| understand_ that delivery will be _" $x+a in $Y+b months
| for $Z+c money"_. In fact, the original contract they
| signed made it clear to them what the cost and time was
| for changing requirements.
|
| More to the point, when they want to make a change, they
| can balance the need for the change against the cost and
| time. Even better, because they know these things
| upfront, _someone_ at the client will have to approve the
| cost and delivery time for the new requirements. That
| person is not going to give the supplier a blank cheque.
|
| It's a good deal better than _" We deliver working parts
| until you are satisfied or until you run out of money. We
| cannot tell you in advance how much this will cost and
| how long it will take."_
|
| I mean, if experienced developers are unable to get their
| software development supplier to deliver with only a
| small margin of money/time overruns, what hops is there
| for the procurement person at any company?
| fabioborellini wrote:
| This is a great piece. My software engineering training
| just held the assumption that the world runs on agile
| processes by now. Waterfall-like processes were a
| historical reference and a failure.
|
| Since external customers and non-swe stakeholders expect
| binding contracts and even waterfall, I would consider it
| essential to learn how to interface agile processes with
| the said contract-driven stakeholders. Telling them that
| we are trying our best just doesn't work.
| t43562 wrote:
| It's why contracted-for software is so awful -
| contractors do absolutely anything to meet the conditions
| and then they're gone and not responsible anymore.
| lelanthran wrote:
| > It's why contracted-for software is so awful -
| contractors do absolutely anything to meet the conditions
| and then they're gone and not responsible anymore.
|
| What's the alternative? Never have contracted-for
| software? Only accept contractors who are prepared to do
| Agile?
|
| How does the procurer then put out bids, without having
| requirements up front?
|
| How do they evaluate bids from various suppliers without
| knowing what the final bill is? How do they shortlist the
| three "best" bids with no costing information? How do
| they even know if they can afford it?
|
| How are the suppliers supposed to submit bids without
| knowing what they are going to bill for?
|
| How does audit make sure that the process was fair?
|
| Once you start supplying/developing software for
| companies that are large enough to have a procurement
| department, you better believe that the process all runs
| on paper[1].
|
| [1] Or the digital equivalent.
| mindcrime wrote:
| Note that the AM doesn't say not to create documentation,
| or use processes and tools, etc. It just says to favor
| the alternatives with the implication that you have to
| exercise some judgment and discretion on deciding what to
| do when. The AM in and of itself isn't a methodology and
| it isn't terribly prescriptive. It's a high level
| description of a general notion of how to approach
| things, which can be (and should be) tailored to your
| circumstances.
| jacobr1 wrote:
| > "Customer collaboration over contract negotiation"
|
| The distinction is more about how granular you need
| things. Do you need to negotiate every piece of business-
| logic and get signoffs on mockups up-front, and in the
| case of paying customer, rather than internal stakeholder
| potentially including placing them into a legal SOW? Or
| can you just agree to a bullet-list of high level
| functionality, and then establish a working arrangement
| to receive feedback and refinement. Build and MVP and get
| some use, then make it better. Likely the initial
| understanding of the requirements was flawed anyway, so
| being reactive to the change, with buy-in from the
| customer will be a better plan for success. But yeah,
| this might not work with physical products.
| rerdavies wrote:
| I can't think of anything more actively harmful than
| implementing requirements that are wrong.
| fijiaarone wrote:
| Better to death march irrelevant requirements to
| bankruptcy than adapt to reality?
| LAC-Tech wrote:
| Theres a third option - see if you can think of it!
| gardenhedge wrote:
| How do you pronounce Fauxgile? I've heard of "Fragile"
| before.
| gymbeaux wrote:
| I like Agile, but I hate "Agile" (that is, how Agile is
| interpreted and implemented by the management of the
| companies I've worked at). I worked at Allstate years ago,
| and was on the team that piloted Agile (Scrum). It was done
| by the book, and I thought it was awesome. We had a quick
| scrum meeting each day, and the retros and plannings were
| only on Wednesdays. Sprints ended on Wednesdays. Most
| companies have their sprints start or end on Monday or
| Friday, but those are COMMON days for people to take PTO,
| nevermind national holidays are usually on those days. That
| was the first company i worked at which was Agile, and I
| haven't been to a company since that did it as effectively.
| Ironic that it was Allstate. Just about everything else about
| the company absolutely sucked.
| rerdavies wrote:
| Wednesday to Wednesday is brilliant! Thanks.
| awill88 wrote:
| Feel like I would've said something like this at the
| beginning of my career.. you're gonna go thru it, you'll see.
| None of what you're saying makes a lick of sense.
| GrabbinD33ze69 wrote:
| ITT: we observe the sheer amount of ignorance & naivety that
| rears its ugly head when stemlords attempt to discuss any
| sort of social issue / concept. It's crazy how one would
| interpret you pointing out the slight misogynistic undertones
| of the phrase you quoted as "making things political". I'm
| not going to mention any popular figure by name as that would
| be quite inflammatory, but it's not wonder certain
| individuals can disguise terrible opinions as the "facts &
| logic" based take & especially dupe men who are in a stem
| field. Really reinforces the stereotype of male
| engineers/scientists who think their field's knowledge
| somehow universally applies to the less "technical" sciences
| such as social sciences.
| [deleted]
| pydry wrote:
| >I really feel agile has killed the happiness of our industry
| because it's met with a lot of back and forth, meetings,
| rituals, and meta-work and not actual productivity (If agile
| is done well though it can be amazing but that's another
| topic to me)
|
| All that stuff you hate isnt unique to software. It's just
| capitalism.
| mangosteenjuice wrote:
| It's not just capitalism. Bloated management and wasteful
| processes are problems under feudalism and communism too.
| jpatt wrote:
| If anything, the modern management structure more closely
| resembles a mini-communist state than a capitalist
| system.
|
| Each department's revenue goes into a shared pool, which
| is distributed amongst the company in annual planning
| cycles by an unelected board of representatives. Who gets
| what is as much a function of meritocratic principles
| like department revenue as it is of who happens to have
| senior leadership's ear that year (how many times have
| executives been convinced X is the future, we need more
| X, with no concrete performance to back that up?).
|
| There are some larger, more sophisticated companies that
| break this mold, but more the exception than the rule, I
| think.
| carom wrote:
| I have been saying this. Large corporations are command
| economies! There is a ton of bureaucracy too.
| kraig911 wrote:
| Before I was in this industry most other things aren't
| ritualistic in their delivery. In retail, in healthcare, in
| hospitality, in television - it was very much quality/event
| driven. A thing was done it can't continuously improved
| upon. Software (at least relative to me) is like working on
| a dish as a chef that is never complete. A patient that
| never is healed etc. It's because so much about ritualistic
| definition of the task over and over. In mission critical
| scenarios I do feel waterfall is better. Agile is something
| where a small team can actually make something over time,
| lots of time but it's become a thing where meetings (and
| their number) are measured as part of the success of a
| project. Not the actual delivery.
| pydry wrote:
| I'm guessing in retail you weren't a walmart greeter.
| LegitShady wrote:
| wait wait you think meetings, rituals, and meta work didn't
| exist in communism?
| faddypaddy34 wrote:
| The poster most likely thinks that communism/socialism
| are utopia producing methodologies that have never been
| tried for real and all evils are because capitalism.
| pjlegato wrote:
| All that stuff is actually _even worse_ under alternative
| economic systems. Spend a few hours talking with someone --
| anyone -- who comes from a Communist country and ask them
| about this.
| massinstall wrote:
| Why is this saying misogynistic?
|
| Because it's a statement about men or because of the implied
| possibility they could be unhappy in their marriage?
|
| Also, why is it horrible?
|
| It appears this world has become manically trigger-happy to
| label something as _-ist or_ -istic, when it contains even
| only a hint of something someone could possibly understand
| the wrong way.
|
| It would be curious to examine in a psychological study if
| this reinforced behavior has developed more due to a subtle
| social reward system for the "labelers", or due to a
| punishment system for the "non-labelers".
| kraig911 wrote:
| To me it's misogynistic because when I heard it first it's
| implied that my happiness is tied to a woman. Since I'm
| happily married and very much in love I know that without
| her I'd probably end up being a philosopher pondering
| problems without answers to run away from the trauma of
| losing her. I've been through it before :)
| Idk__Throwaway wrote:
| And how is implying your happiness is tied to a woman
| misogynistic?
| multiplegeorges wrote:
| It reduces women to instruments to serve men's happiness.
| tmn wrote:
| This is the logical fallacy prevalent in these types of
| 'this offends me' reactions. You have completely
| fabricated this takeaway.
| dgfitz wrote:
| A.) No it doesn't, not even a little bit. B.) He said he
| was happily married, he didn't say his happiness it tied
| to a woman, you're twisting words.
| Gud wrote:
| No it doesn't.
| weakfish wrote:
| Great argument! Let me try.
|
| Yes it does.
|
| Did it do it right?
| Gud wrote:
| Parent didn't provide an argument and the burden of proof
| is on them.
| concordDance wrote:
| You can and should do better than them, not descend to
| their level. It's obvious to any reader that the parent
| was just making a bold assertion.
| slt2021 wrote:
| replace woman with kids. Happy parents are happy parents,
| unhappy parent is a philosopher parent.
|
| doesnt sound like any -ism to me
| kraig911 wrote:
| For sake of mental gymnastics I'll humor you. It's
| misogynistic because it's rooted in I presume in my
| culture that women generally don't sit and ponder
| problems, or resort to alcohol, drugs and crime as bad as
| men when things go bad. Women generally move on. So that
| belies a certain belief that women are the cause of all
| problems - And that is misogynistic.
| jasmer wrote:
| The statement does not imply those assumptions, and even
| if it did, it would not be misogyny. The fact there is so
| much discussion about this is the 'issue' here and it's
| toxic.
| peoplefromibiza wrote:
| > To me it's misogynistic because when I heard it first
| it's implied that my happiness is tied to a woman.
|
| Nowhere it is implied that an unhappy marriage for a men
| is due to women in the marriage, if I had to guess,
| unhappiness in marriage for men is tied to having kids.
|
| Anyway, focusing on the fact that it says "men" instead
| of focusing on the fact that it says "unhappiness" says a
| lot about the priorities people have nowadays.
|
| It's like reading "The Fox and the Grapes" and focusing
| on the fact that there's a talking fox trying to eat
| grapes.
| schrodinger wrote:
| There's a slight implication because it only covers men
| that women are the source of unhappiness (e.g. the nagging
| wife trope), but I agree it's trivial and likely
| unintentional. Agree with sibling, just as applicable as
| "happy married people are happy partners, unhappily married
| people are great philosophers".
| xwdv wrote:
| [flagged]
| daveguy wrote:
| Not being a dipshit is not the same thing as "bending to
| people's demands."
| LAC-Tech wrote:
| I wish I had the confidence in life to genuinely think
| anyone who thought or spoke differently to me was just a
| dipshit.
| wpietri wrote:
| That's not what he said, and I doubt it's what he meant.
| Many people who disagree with me are not dipshits, but
| the ones who are seem to take positive joy in being
| disagreeable.
| schrodinger wrote:
| Language is lovely because you can find so many ways to
| express creativity! I don't think
|
| "Those happily married make great partners, while those
| unhappily married make great philosophers!"
|
| is any less colorful than the original.
| xwdv wrote:
| It's bland, safe, and lifeless. The statement has no
| bite.
|
| The original statement will be read by men and some men
| will connect to it right away, because rather than
| envision some abstract person, they are made to
| immediately picture a man, and in that image they may
| recognize themselves, like looking at a mirror.
| ajmurmann wrote:
| > The original statement will be read by men and some men
| will connect to it right away, because rather than
| envision some abstract person, they are made to
| immediately picture a man, and in that image they may
| recognize themselves, like looking at a mirror.
|
| Sorry, are you saying that the audience of the statement
| is on purpose only men? If so, how could you possibly
| support any claim that it's not misogynistic?
| lelanthran wrote:
| > Sorry, are you saying that the audience of the
| statement is on purpose only men?
|
| Isn't it?
|
| Wasn't Socrates replying to a question from a young man
| when he (allegedly) said that?
|
| Since the origin of that quote is _directly_ in response
| to a man, isn 't it aimed at ... men?
|
| [1] https://www.quora.com/Did-Socrates-really-say-if-you-
| get-a-b...
| ajmurmann wrote:
| I really want to take your argument as a reason why it's
| 100% ok to phrase it exclusionary, but then I get a
| response like this
| https://news.ycombinator.com/item?id=34376163 and am
| reminded how that general tone will keep women away from
| our industry rather than attract them.
| xwdv wrote:
| A long time ago this industry was _built_ on women, the
| first programmers were women. It was a female dominated
| field. So what happened? The women stopped giving a fuck
| and the men took over.
|
| The industry has plenty of attractive qualities for any
| sex: Good money, good jobs. These far outweigh the
| occasional toxic male who is easily put down these days.
| If women aren't signing up, then maybe they just don't
| care about computers as badly as people want them to.
| lelanthran wrote:
| > that general tone will keep women away from our
| industry rather than attract them.
|
| I don't "tones" have anything to do with it; in the 80s,
| Law, Accounting and Medicine[1] was absolutely
| _dominated_ by men. If you think that introverted nerds
| are sexist, they have nothing on how doctors, lawyers and
| accountants were, nor how sexist the purchasers of those
| services were (often assuming that the men would be more
| competent).
|
| And yet, today those professions have as many (if not
| more) females than males.
|
| It's a stretch to think that general tone of an industry
| was responsible for females leaving the profession filled
| with introverted IT nerds and moving to high-powered and
| high-status executive professions.
|
| [1] Other than nurses, in which men are still only a
| rounding error.
| thegrimmest wrote:
| It's quite possible to target a statement at a male
| audience without a disclaimer and yet still not be guilty
| of misogyny.
| ajmurmann wrote:
| The statement was made in a discussion about working in
| tech, not at a free masons lodge
| xwdv wrote:
| Most people here are men. The content will reflect that.
| Get over it.
| seadan83 wrote:
| Is that not part of why this industry has a problem?
|
| In isolation, it is innocuous, and has the caveat emptor.
| Though, if you get slapped with, you can't be a great
| philosopher (for what are happily or unhappily married
| women other than just spouses), you can't be police, fire
| fighter, coder, CEO.. it's just another slap in a series
| if many that occur daily. So, the idea is stop with the
| isolated examples, and perhaps the bombardment will
| lessen
| jasmer wrote:
| Yes, but, there is absolutely nothing wrong with what he
| said and not reason to correct anything.
| elil17 wrote:
| >most people stuck in unhappy marriages are men
|
| That is wildly untrue. The research on whether men or
| women are more satisfied in their marriages shows that
| they have about the same levels of satisfaction.
|
| For example:
| https://onlinelibrary.wiley.com/doi/10.1111/jomf.12077
|
| Not really sure why the demographics of philosophers
| effects the impact of the statement. Most philosophers
| are white, would it have been more impactful if the
| statement had brought race into it?
| xwdv wrote:
| If you could bring race into it somehow then yes the
| statement might seem more based in historical precedence,
| rather than some idealistic fantasy world of hyper
| diversity, assuming most unhappily married men are also
| white.
| elil17 wrote:
| I don't really get why any of that matters though. Can't
| you just appreciate the sentiment regardless of how it is
| phrased? Seems like your trying to make it political when
| it just isn't.
| xwdv wrote:
| Maybe you should think about who is actually making it
| political, i.e. the people trying to transform the phrase
| into something politically correct.
| elil17 wrote:
| Idk man sounds like they're just taking a phrase and
| phrasing it slightly differently so that it applies to
| more people. You're the one who was offended by that
| doetoe wrote:
| Just a side remark, but "most philosophers are white"
| should probably be "most philosophers you heard about"
| elil17 wrote:
| You're absolutely right
| Retric wrote:
| It's true that only a minority of philosophers are white,
| and people are far less likely to be aware of
| philosophers outside their culture.
|
| But there are less aggressive ways to say it.
| doetoe wrote:
| My intention was not to be aggressive at all, sorry!
| elil17 wrote:
| I felt that they offered a helpful correction
| water8 wrote:
| [dead]
| mejutoco wrote:
| > most people stuck in unhappy marriages are men
|
| If we are counting only heterosexual and 2 people
| marriages, wouldn't the number of people stuck in unhappy
| marriages be exactly 50% men and 50% women?
| brippalcharrid wrote:
| The [perceived] consequences of ending a marriage seem to
| provide more of a disincentive to men, so they are more
| likely to persist in a marriage that they feel they would
| be unable to leave (and then have to support multiple
| households, etc.). The fact that women (in the USA) are
| more than twice as likely to initiate a divorce seems to
| bear this out.
| antonfire wrote:
| "Women divorce men more often than the other way around;
| this seems to bear out that men are more dissatisfied in
| marriage" seems like a stretch to me.
|
| At any rate, it reminds me of the classic physics joke:
|
| > An experimental physicist comes running excitedly to a
| theorist's office, waving a graph taken off his latest
| experiment. "Hmmm", says the theorist, "that's exactly
| where you'd expect to see that peak. Here is the reason."
| A long logical explanation follows. In the middle of it,
| the experimentalist says "Wait a minute", studies the
| chart for a second and says "Oops, this is upside down."
| He fixes it. "Hmmm," says the theorist, "you'd expect to
| see a dip in exactly that position. Here is the
| reason..."
| [deleted]
| antonfire wrote:
| Leaning into society's stereotypes is one way to bend to
| people's implicit demands to change your writing (and
| quite possibly thinking).
|
| But sure, if the metric you're optimizing is raw views
| and smiles and laughs, then probably the way to go is
| leaning into stereotypes. There's a reason those views
| and smiles and laughs are called "cheap".
| Aeolun wrote:
| I mean, I've never heard of any woman being unhappy
| because of a nagging husband.
|
| The source of unhappiness for women seems to be the
| reverse. A husband that's not doing all the things she
| nags about automatically.
|
| I think priorities are just fundamentally different
| somehow.
| peoplefromibiza wrote:
| [flagged]
| jgil wrote:
| > Was Aristotle misogynistic?
|
| Yes. https://en.wikipedia.org/wiki/Aristotle%27s_views_on
| _women
| zmgsabst wrote:
| The introductory paragraph makes it seem like the extent
| of your claim is he noticed the same behavioral trend as
| most psychology surveys:
|
| > Among women's differences from men were that they were,
| in his view, more impulsive, more compassionate, more
| complaining, and more deceptive. He gave the same weight
| to women's happiness as to men's, and in his Rhetoric
| stated that society could not be happy unless women were
| happy too.
|
| And the modern psychology:
|
| https://www.bbc.com/future/article/20161011-do-men-and-
| women...
|
| I think you're really stretching the word "misogyny" when
| you're using it for people who accurately describe
| reality and view male and female well-being as equally
| important for society.
| philosopher1234 wrote:
| You are a misogynist. This is literally the first
| sentence. Your post is shamefully misleading.
|
| > Aristotle saw women as subject to men, but as higher
| than slaves, and lacking authority; he believed the
| husband should exert political rule over the wife.
| peoplefromibiza wrote:
| [flagged]
| selimthegrim wrote:
| Wasn't he the guy who said that woman had a different
| number of teeth than men but never bothered to check?
| bobobob420 wrote:
| You went too deep. Never go too deep
| schrodinger wrote:
| I'm sorry, it really isn't a big deal and I don't think
| anyone would be triggered or offended by the quote! And
| of course historical context matters. The poster was just
| proffering a friendly reminder that to push society
| forward it's helpful to consider these things.
|
| It's just like changing our default branches from master
| to main, honestly probably not a huge deal to any
| rationale person, but the cost is negligible so why not?
|
| It's possible to be empathetic and considerate, making
| minor adjustments (and also not judging those who
| innocently don't) without being the "woke" police!
| peoplefromibiza wrote:
| > he poster was just proffering a friendly reminder that
| to push society forward it's helpful to consider these
| things
|
| It is totally not.
|
| As Ricky Gervais put it beautifully, like it or not, if
| you categorize the people of the past with the standards
| of today, you are preparing the people of the (near)
| future to categorize you about what you say today.
|
| Now imagine that people think of Aristotle as a
| misogynist, like if it is actually important, he died
| 2,300 years ago after all and nobody studies Aristotle
| because "and now let's read about that guy who hated
| women, because it's something important to learn: women
| are trash", but
|
| _By the 1930s, a new kind of human zoo appeared in
| America, nude shows masquerading as education. These
| included the Zoro Garden Nudist Colony at the Pacific
| International Exposition in San Diego, California
| (1935-36) and the Sally Rand Nude Ranch at the Golden
| Gate International Exposition in San Francisco (1939).
| The former was supposedly a real nudist colony, which
| used hired performers instead of actual nudists. The
| latter featured nude women performing in western attire.
| The Golden Gate fair also featured a "Greenwich Village"
| show, described in the Official Guide Book as "Model
| artists' colony and revue theatre."_
|
| Or this
|
| https://en.wikipedia.org/wiki/Human_zoo#/media/File:Afric
| an_...
|
| Sorry if I stand with Aristotle, despite him being a man
| of his times, and not with 20th century human zoo.
|
| edit: to put it simply, should we talk to German people
| or everytime they try to say something we should shut
| them up reminding them that they did _the holocaust_?
|
| When I disagree with someone from the US, can I use _"
| you are the only people in history to have dropped two
| atomic bombs on civilians, you are wrong by design!"_?
|
| Why Aristotle is problematic, but nobody says "he was a
| Trump but a lot more intelligent than Trump and actually,
| now that I think about it, he never said <<grab them by
| the pussy>>, so Aristotle was less misogynist than
| Trump"?
|
| Aristotle has never been POTUS.
|
| I understand pushing society forward, so why blame people
| who have died thousands of years ago for things they are
| not responsible of today?
|
| Does someone really think that quoting that sentence from
| Aristotle will plant the seed of misogyny in people's
| mind?
|
| Is this really the kind of trust we have in each other's
| intelligence?
|
| I believe people can read the context loud and clear.
| philosopher1234 wrote:
| He was a misogynist. That's a fact. Yes, the standards
| have changed. It doesn't mean we need to throw out
| everything he said, but sticking your head in the sand
| and ignoring a basic quality of his thought because...
| I'd not know why honestly? It's threatening? thats not
| the way forward.
| axxto wrote:
| > _But most of all, dear friends, that quote is 2,300
| years old! Was Aristotle misogynistic?_
|
| Yep
|
| > In his work Politics (1254b13-14), Aristotle states "as
| regards the sexes, the male is by nature superior and the
| female inferior, the male ruler and the female subject".
|
| > While Aristotle reduced women's roles in society, and
| promoted the idea that women should receive less food and
| nourishment than males, he also criticised the results: a
| woman, he thought, was then more compassionate, more
| opinionated, more apt to scold and to strike. He stated
| that women are more prone to despondency, more void of
| shame or self-respect, more false of speech, more
| deceptive, and of having a better memory.
|
| _________
|
| > _apparently nobody has ever read the great
| philosophers._
|
| Yep
| peoplefromibiza wrote:
| [flagged]
| mahogany wrote:
| I broadly agree with your point, but then you decided to
| search for quotes that apparently support your argument,
| and you picked... Schopenhauer, in a discussion about
| misogyny and marriage, which is pretty hilarious.
| peoplefromibiza wrote:
| narrative is King in 21th century my friend.
|
| I did not make the rules.
| feoren wrote:
| You're clearly passionate about something here, but it's
| not totally clear what it is or why. It might be
| interesting to read what you have to say, but you need to
| chill, organize your thoughts, and stop calling other
| posters idiots for disagreeing with you. Right now it
| feels like we're catching half of an angry shower
| argument against someone who's not here.
|
| I can tell, because I've made posts like this before, and
| I always regretted it later. Have your angry argument in
| a journal or text file (Lately I've really liked Markdown
| with source control). Then revisit it later, and add in
| the side you're arguing _against_. Then revise it so that
| you 're actually making a clear point, and remove all the
| personal insults. Then post it here, because I want to
| read it. But until then, I have no idea WTF you're on
| about or why you're so defensive of a very-long-dead
| philosopher.
| now__what wrote:
| Aptly stated. I would like to save this as a copypasta
| response to innumerable similar internet comments.
| bennysonething wrote:
| What? I found their post informative and yours extremely
| patronising. They're not defensive about Aristotle, they
| are pointing that the quote seems to be misinterpreted
| because it's about relationships between men and woman.
| operatingthetan wrote:
| See: https://news.ycombinator.com/item?id=34373176
|
| edit: welp it's flagged now but they straight up called
| another poster "stupid."
| conductr wrote:
| There's a lot of things like this that I blame mostly on
| the growth of what we're doing here. We're communicating in
| a low fidelity text only fashion and doing it without any
| knowledge of _who_ each other are and how our word choices
| will be received. We definitely don't know _who_ is lurking
| or reading or may take offense once I hit the reply button
| on this form.
|
| Had that been said in person, even with someone we only
| recently met, we'd have "known" what it was meant to mean
| and that it was just a figure of speech to support their
| main point. Online, people will read every word selected
| and choose to vilify you for using a pronoun or some other
| random extreme literal take on your word choices without
| really considering what your intent or meaning or that you
| is (often there's not much, it just happens to be the
| choice of words they made while typing on a tiny device and
| trying to be concise). It's also not considered that online
| we're intermixing generationally, culturally, economically,
| and so many ways. When a 50 year old person says something
| like the word "retarded" it may feel normal and they are
| ignorant of the fact that anyone under ~30 knows not to
| even say that word, it's the "r" word. Then you have the
| other "n" word that everyone knows is unspoken except it's
| found and heard everywhere because some people can and do
| say it steadily.
|
| As an example, I frequent a local subreddit for my city.
| Something that regularly comes up is crime and homeless and
| such. If you have anything to post there. Someone else will
| invariably reply with yes but redlining, Jim Crowe,
| disenfranchised citizens, etc. Those are all base general
| knowledge and historical facts for sure. I think everyone
| is well aware of them. But, it's difficult to have any
| discourse when the audience expects a full historical
| account of why the situation exists before solutions can be
| discussed. It's pretty tiring and I've basically stopped
| chiming in on those kinds of things.
|
| TLDR: communication is hard and text only is really hard.
| lelanthran wrote:
| > Why is this saying misogynistic?
|
| It's not; it's the result of a vocal and aggressive mob -
| people are taking care to not draw the attention of the
| mob.
| the-printer wrote:
| There has to be some sort of "Streisand Effect" phenomenon
| that can be applied to interpersonal communications, where
| by mentioning a thing in conversation that you hope _not_
| to entertain, it gets entertained as a consequence of it
| being mentioned.
|
| > It would be curious to examine in a psychological study
| if this reinforced behavior has developed more due to a
| subtle social reward system for the "labelers", or due to a
| punishment system for the "non-labelers".
|
| This is intriguing by the way.
| Aeolun wrote:
| I think there is a strong punishment system for the non-
| labelers. People that feel strongly about this stuff are
| really rabid, and seem to spend all their time calling
| people out on perceived slights.
| alexvoda wrote:
| I see there are many people commenting on the ethical value
| of that saying.
|
| To understand it better it is worth noting that it is a
| bastardization of this misquote commonly attributed to
| Socrates: "By all means marry; if you get a good wife,
| you'll become happy; if you get a bad one, you'll become a
| philosopher."
|
| As detailed in this ( https://qr.ae/pvP31C ) answer on
| Quora, Socrates never said (or was never recorded to say
| it, he didn't write down his philosophy) this exact thing.
| But there is a recorded dialogue that is plausible as the
| source of the simplified quote.
|
| While less clear from what kraig911 said or from the
| original dialogue, the commonly spread (meme) version of
| the quote, which I pasted above, makes the misogynism
| clear. I hope further explaining that is not necessary.
|
| It is important to note that Ancient Grece was very gender
| unequal, so a misogynistic quote in that social context is
| not something surprising, even for one of the brightest
| minds. That is just how society was in those times, and
| those philosophers did not get the benefit of hindsight we
| have today.
|
| Besides, as stated above, Socrates didn't actually say that
| misquote. He was commenting about the challenges of his
| relationship with his wife. From that dialogue, it is even
| implied it was a conscious decision he made.
|
| The misquote is especially dreadful because it is a
| generalization over the entire feminine gender. I am now
| quite curious when exactly in history did the misquote take
| its commonly known form.
|
| I am quite surprised that of all the people commenting, no
| one attempted to go to the source of that meme. Instead,
| everyone just espoused their viewpoint. I wish HN to be a
| place of knowledge seeking, not a place of culture war.
|
| Edit: looking into this a little deeper, Spencer McDaniel,
| the one who wrote the Quora answer linked above, has an
| entire blog about ancient times and expands on the issue of
| misquotes:
| http://talesoftimesforgotten.com/2019/07/16/fake-and-
| misattr...
| antonfire wrote:
| > It appears this world has become manically trigger-happy
| to label something as -ist or -istic
|
| Also to label something as maniacal, perhaps.
| gsk22 wrote:
| There are plenty of layers at which it's misogynistic, but
| the most obvious one perhaps is that it wholly centers
| around the man in the relationship. Why must the wife be
| the source of the husband's unhappiness ("nagging wife"
| trope)? Why does he get to be the great philosopher if
| they're both unhappy?
|
| You can say "it's just a saying, it would be equally true
| with the roles reversed" -- but then, why aren't they?
|
| Sure, on the misogyny scale, it's pretty mild, but sayings
| like this that implicitly reinforce the male-centered world
| we live in are in some ways the most insidious.
| concordDance wrote:
| In an unhappy marriage the other person is normally the
| source of unhappiness. Not always of course (I knew a guy
| who got divorced because he felt he'd missed out on
| having more relationships).
| deadpannini wrote:
| The standard you've laid out proposes that any statement
| about a man's experience in a relationship is by
| definition misogynistic, because it's centers the man
| (and, of course, erases women). Do you stand by that?
|
| Additionally, consider that _you_ are the one bringing
| the nagging wife trope into this: it 's merely one of
| many possibile explanations and unhappy marriage.
| ttyprintk wrote:
| It's only misogynistic if the husband:
|
| 1. Can only be married to a woman, sometimes a pre-arranged
| woman
|
| 2. Has religious or cultural norms keeping it that way
|
| 3. Improving the marriage is the woman's territory
|
| This is probably a realistic aphorism for a larger group of
| people than those who can call it misogynistic.
| lo_zamoyski wrote:
| It is currently culturally fashionable to construe things
| in this manner, so unsurprising. It is humorless and lacks
| common sense. Reasonably intelligent people understand
| context. They do not flatten all of reality and reduce
| everything to their favorite pet paradigm, projecting
| uncharitably all sorts of weird baggage onto the most
| innocuous of statements.
|
| So now you can't make a quip about wives unless you also
| make a quip about husbands (or else generalize it to
| "persons") though even these are now too restrictive for
| some. Heaven help you if you dare observe that there are
| differences between men and women, complementary
| differences no less, that lead to humorous tensions between
| them and peculiarities particular to each that surface
| within their shared lives.
|
| Shall we raise a toast to ourselves, savaged men (and
| women!)? Humor is dead. And we have killed it.
| emadabdulrahim wrote:
| Common sense is dead. Certain groups of people lack self
| and/or social awareness to notice that they've replaced
| religion with ideology. For example, we criticize
| religion for shaming many parts of our sexuality "Welcome
| to church, you're a sexual being and you should be
| ashamed". Now that's been replaced with "You're a man,
| you should feel guilty because you're from the oppressor
| group." etc.
|
| Welcome to Western society, you're privileged and you
| should be guilty and ashamed.
|
| How did we get here?
| cjcenizal wrote:
| I think recognizing one's privilege is uncoupled from how
| you choose to feel about it.
| Dudeman112 wrote:
| For most people it's not
|
| The expression "privilege" itself makes people feel
| attacked and get defensive. If you say the same exact
| sentence replacing "privilege" for the definition and it
| greatly changes how people react to what you say
| Murfalo wrote:
| OK I do think there is an issue with wokeness in society.
| But, I also think there is a problem with anti-wokeness
| that can be seen here with people chomping at the bit at
| the first (poorly attributed) use of "misogyny". Women
| aren't even mentioned, and the only way I see
| them/misogyny even entering the equation is if you make
| the rather odd pair of assumptions that an unhappily
| married man must: 1) be married to a woman, and 2) be
| unhappy exclusively as a result of his wife. You could
| attribute it to the result of the woke hivemind's
| effects, but you could also very much not! It's
| effectively an unintentional strawman...
|
| I think there is probably a happy medium of wokeness that
| can be reached via measured discussion between respectful
| adults. I think in real life (at least in my experience)
| people are willing to have those discussions, and are
| much less polarized and divisive than the internet/cancel
| culture might have you believe.
| Beltalowda wrote:
| You can just replace "men" with "people" and it still works.
| misja111 wrote:
| > I really feel agile has killed the happiness of our
| industry because it's met with a lot of back and forth,
| meetings, rituals, and meta-work and not actual productivity
|
| Agile was created to beat exactly those things that you are
| mentioning. Then Agile became big, enterprise became aware of
| it and smothered it with their rituals, processes and
| bureaucracy. And now we're back where we started again.
| t43562 wrote:
| At higher management levels people are trying to "achieve"
| some goals and of course "agile" means that you are
| constantly evaluating what to achieve and discarding some
| of it while perhaps adding new things. There's less agility
| higher up because I think it takes too long for any of
| those goals to be proven stupid (or proven smart) so it's
| waterfall ontop and agile underneath and that's obviously a
| clash.
| nouveaux wrote:
| This 1000x. For a larger project, I asked and got approval for
| a POC. When I submitted the POC with feature flag for review, I
| was told by the same management that it wasn't "production
| worthy". Never burned out faster in my 20+ year career.
| goodpoint wrote:
| > Some software companies can turn even the simplest tasks into
| a grueling series of processes, endless meetings
|
| You mean 95% of companies.
| MuffinFlavored wrote:
| > I can almost guarantee that you're just at the wrong company.
|
| Even if this is true (which it most likely is), there's no
| guarantee the company you move to (in your quest of finding
| "the right company") won't either a) also be the wrong company
| again right off the bat or b) become the wrong company again.
|
| I've kind of just given up. I've accepted I'm basically a
| "technical plumber". Take data from this system/vendor in this
| format, convert it to another, make low six figures, have
| benefits, try to focus on life outside of work.
| fijiaarone wrote:
| I've worked at every company.
|
| The grass is always brown -- when there is any -- and the
| septic tank stinks.
| fldldosn wrote:
| I'm in the same boat, and I just want to say: we should try
| to be grateful. For the vast majority of people, what matters
| in life is what is outside of work, and maybe it's because I
| grew up in an impoverished rural area but earning low six
| figures to do a fairly simple job for a few decades and not
| breaking our bodies doing a physical trade, working
| remotely..
|
| I think about my ancestors a lot, toiling in fields and
| fighting in horrific wars
|
| We have it good, we really do
| ugh123 wrote:
| True, but thats why you should network with current and
| former engineers at the company to get the real dirt
| digitalsushi wrote:
| Three years ago I was stuck at a huge fortune 100 with all
| the ceremonies, business language, and paycheck collectors. I
| started to shop around. I found an amazing place, a company
| that was a software company not not a company that happened
| to write some software.
|
| The interviews went amazing, everything was Star Trek utopian
| future amazing, it was like the fantasy I had about where I
| wanted to work had manifested. I got a job offer, and took it
| immediately.
|
| The first day of work, no one on my team was there to let me
| in, so I hung out in the lobby for several hours waiting for
| anyone brave enough to get me to the badge people so I could
| open the door on my own. By five months in, I'd not had a
| manager check in yet, no one on the team would talk to me,
| and I realized I was a professional bench warmer. I'd been
| bamboozled, body-snatched from my boring, process-jammed,
| low-progress IT job.
|
| Fortunately the fortune 100 took me back. I hadn't burned any
| bridges on my way out, and my seat was still warm. My cube
| was still there, my gear all waiting for me to just log right
| back in 6 months later like I was simply on a long break.
|
| Three years later I'm still here. I'm terrified to go looking
| again cause I can't have my heart broken twice so soon. I
| have no idea how to interview well enough to detect a trap. I
| think my age has a lot to do with it (I'm in my mid 40s and I
| average about 7 years per company so I don't experiment a lot
| with this).
|
| I think that your strategy is the same as mine and that you
| should be rewarded for sticking with it, because there's
| success in it even if you're not constantly being entertained
| by solving the big interesting problems. Running a little
| personal infrastructure to learn the next big
| platform/language/thing is always a great hobby for people
| who can do a little more work outside of work, and just
| having interests that don't earn you anything at all are the
| most rewarding for finding brief moments of happiness.
| rco8786 wrote:
| I'm really confused. What was the motivation of the hiring
| company here?
| nerdile wrote:
| More context at
| https://news.ycombinator.com/context?id=29969359
| gedy wrote:
| I'm still kinda confused - did you have no work to do at
| all? Or you just were expecting some collaborative team
| work that's not there? I agree lack of communication
| seems extreme, but if you are working that's not exactly
| bench warming.
| drdec wrote:
| You should have asked to go remote and avoid the state
| taxes.
| slt2021 wrote:
| pls name a company, I want a job at that company
| carom wrote:
| Google in Sunnyvale was like this. We had lunch together
| but the office was eerily quiet. People would catch
| themselves talking, apologize, then go to a meeting room
| if they wanted to continue. Low key hated it and I'm not
| a social person and prefer quiet while working.
| entropicdrifter wrote:
| Seriously, if I could do all of my work without people
| trying to talk my ear off all day and let me keep my work
| life and social life truly separate, that sounds ideal to
| me.
|
| "Oh the tech was textbook perfect but I didn't like that
| nobody wanted to stand around and bullshit all day"
|
| Like bruh.
| throwanem wrote:
| I dunno. Sounds to me like the kind of culture where the
| first way you hear about poorly communicated expectations
| is when you're asked to sign a PIP.
| andrewflnr wrote:
| That is a rather different story indeed. They made it
| sound here like they weren't working at all in that five
| months.
| floydian10 wrote:
| Maybe hitting some hiring target?
| icedchai wrote:
| This happened frequently in the dot-com era. There was
| tons of over hiring to inflate the budget and get more VC
| money. I remember one company I worked for raised $8
| million (a pretty good size A round for late 90's), then
| immediately dumping $1 million into office renovations
| for a second location down the street.
|
| That office needed to be full. We'd hire guys who could
| barely spell HTML. The next round was $20 million or so.
| More hiring. It was like monkeys banging on keyboards.
| There were no code reviews, no process, nothing like
| that. We hired some of the most clueless management you
| could possibly imagine.
|
| The product itself was half baked and ill-conceived. But
| we just kept on hiring. Eventually 2001 came and there
| were mass layoffs. I was not among them, but I left on my
| own about a year later. Eventually there was a fire sale
| and everything was sold for pennies on the dollar.
| kodah wrote:
| Ageism does occur in this industry, but I've mostly heard
| it around associating various levels with age or years of
| experience. For instance, at a financial product company I
| worked for I saw a man who went on to become a Googler get
| cut from our interview because he "had too much experience
| to be a senior". For context, most of his background had
| been in contracting and he'd only recently really invested
| himself in DS&A knowledge (the kind larger firms look for).
| The kind of companies he had worked for put his skills
| cumulatively around Senior but he'd been in the industry a
| long time.
|
| There's "innocent sounding" explanation for the managers
| decision to cut the interview, but they're all tainted with
| some form of ageism.
| jcbrand wrote:
| > so I hung out in the lobby for several hours waiting for
| anyone brave enough to get me to the badge people
|
| Did you consider asking someone going in or out to help you
| get a badge or to put you into contact with the right
| person?
|
| Sounds like you passively waited for someone to come and
| help you, which might be fine for a short while, but
| eventually it's better to take action.
|
| I've never heard of a "professional bench warmer" in
| software development. It's not as if devs get injured
| regularly and need replacements. Why do you think they'd
| hire you just to not give you anything to do?
| v-erne wrote:
| >> I've never heard of a "professional bench warmer" in
| software development.
|
| I think this is real.
|
| My friend who is serial Project Manager (he works for big
| corps here in Poland and changes job almost every year
| for last 15 years) actually uses the term "on bench" for
| programers that do not have projects assigned to them and
| he claims that he quite often hires people before project
| is confirmed, so from time to time some people are left
| hanging without free chairs when music stops.
| nunez wrote:
| yeah that's how a lot of consulting companies work
| wojciii wrote:
| I have 20+ years of experience in different companies
| (software and just using software);and I never ever heard
| of this behaviour.
|
| I never changed job (Unusually work 2-4 years at one
| company) where I didn't have everything ready on my first
| day.
| blue_daisies wrote:
| I have heard of this at Infosys in the US
| jokab wrote:
| IBM and Accenture in the Philippines.
| wojciii wrote:
| Ah. I live in the EU where they a person is quite
| expensive to onboard and it makes no sense to hire people
| to be idle.
| PL_kolek wrote:
| I can confirm that - "on bench" was a real term used in a
| software house I worked for in Poland. I think it becomes
| a necessity when your company doesn't have a product on
| its own but delivers projects for other companies.
| Depending on the needs of your clients, the projects may
| be short 3 months stints or longer years long
| cooperations. In an environment like that firstly you
| want to be able to start working as soon as the contract
| is signed, so you must have some staff available all the
| time, and secondly you don't want to wreck the morale by
| letting your staffing level fluctuate with the workload.
| Hence some people are "on bench", waiting for a project
| to come, doing internal work or upskilling. This company
| was the best one from the ones I worked for in my career
| BTW
| wpietri wrote:
| It happens for all sorts of reasons. Often managers are
| seen as important not because of what they produce, but
| how big their teams and budgets are. In that
| circumstance, hiring people is important, but getting
| anything useful out of them is secondary.
|
| Or it could be pure chaos. Years ago I joined a startup
| that was scaling rapidly. The interview process was
| exciting, the people seemed great, and the compensation
| was very appealing. So I go in on my first day, eager to
| get to work. After sitting in the lobby a while, I'm told
| that they aren't ready for me, and could I come back?
|
| The next day I come in, and they again say they aren't
| ready, they're very very sorry, and that I should come
| back tomorrow. So I do.
|
| The third day I figure, great, now I'm going to get to
| work. But once again, nobody's ready for me. No desk, no
| computer, no nothing. They weakly suggest that maybe I
| could find a corner somewhere and read manuals?
|
| I politely tell them that I think this isn't a match,
| GTFO, and never come back. They go out of business a few
| years later.
| MiyamotoAkira wrote:
| Being in the bench is not unusual for Consultancy
| companies, where there is no necessarily alignment
| between finishing with a client and starting with the
| next one. Or even starting directly on a client when you
| join them.
|
| Quite useful time to spend learning.
| wildzzz wrote:
| Many big government consulting companies will have a
| constant pool of employees that have nothing to work on
| for a few reasons: they have a job but are waiting on a
| clearance to start work, they were hired for/working on
| something that didn't pan out so they are waiting for a
| new job, or they've got a job but the project hasn't been
| given a green light to start working it yet. These
| workers may be able to find some low level work to keep
| busy or they have some training budget that can be spent
| on bootcamps but sometimes there is just nothing for them
| to do other than just spend all day looking at the
| internal job board and canvassing program managers for
| work. The last situation is the worst to be in, you only
| get to bill overhead for so long until you get laid off.
| The good part is at least you're getting paid while
| applying to other companies in the evenings. Unless you
| know there's a position waiting for you, its best to
| spend as much training money as you can and find a new
| company before the lay off comes.
|
| My company likes to do the complete opposite. There is
| always endless work to do because we only hire if there's
| an immediate need for someone. The upside is that you're
| always going to be busy and lay offs are very rare. The
| downside is that we are perpetually understaffed.
| reedjosh wrote:
| I'm sorry you've been burned and it's not easier for you to
| take these risks.
|
| I average about 2 years, and each company has been
| progressively better than the last.
|
| Don't let a bad job hop stop you. To me it's the only way
| to really progress your career.
|
| I've done a huge variety of projects, experienced a ton of
| different management styles, and of course also never
| stagnated compensation wise.
|
| Leetcode kind of sucks, but it's possible to build up
| enough confidence to ace it.
|
| Particularly start by focusing on one area until you see
| all the basic patterns. For me, I was rather weak with
| trees.
|
| Job hoping seems to be the only reliable way to increase
| your comp. I was promoted at Intel and got 11% as a raise.
| Then I bounced and gained another 40%.
|
| From there I doubled entirely. Please do consider your
| value, plus selfishly you'll help keep the software
| engineering market competitive if you do.
| wpietri wrote:
| Yeah, the older I get, the more I'm able to see how companies
| could be so much better, so much more effective. But that's
| not something executives really want most of the time. So I
| think what will eventually drive me to retire is not getting
| tired of making things, but an inability to put up with the
| gap between what's possible and what's actually going on.
| nullsense wrote:
| This. The most succinct way I've ever heard it formulated
| is the quote "not everyone, in the final analysis, actually
| wants their problem solved"
| wpietri wrote:
| Yeah, that's been a hard lesson for me to learn. When the
| nominal purpose differs greatly from the POSIWID purpose,
| I find it very frustrating. Very human, of course, and if
| that were all it was I could work with it. But at least
| in American business culture we musn't talk about POSIWID
| purposes. It'd be so much easier for me if we could just
| say, "Ok, grandboss, we recognize the most important
| thing for you here is you looking amazing to your boss so
| you can climb the ladder. But we'd all like to also get
| some work done for our users, so how can we make
| everybody happy?"
| commandlinefan wrote:
| > in your quest of finding "the right company"...basically
| just a technical plumber
|
| I've come to a sort of depressing realization, 30 years into
| this career: the kind of companies that _will hire me_ are
| usually not the "right" company. I'm not even a plucky
| bootcamp self-motivator, I'm a state-school CS grad who's
| never worked for Google, Facebook _or_ Amazon. The hiring
| processes that don 't filter me out are the sorts of
| employment processes that demand hour-by-hour status updates
| in the form of up-front-estimate timesheets and 24/7 on-call.
| Oh, well, I might actually make enough money to retire some
| day.
| [deleted]
| [deleted]
| meowtastic wrote:
| I have the same issue. I hate leetcode, am a good
| communicator and want to always connect what I build to the
| value it delivers to customers. But the companies that care
| about this the most are startups, and I've had some really
| bad experiences.
| roeles wrote:
| Thanks for this. I have observed the same thing. I wonder
| if anyone on HN has insights into how to find companies
| that focus on customer value.
| 0xdeadbeefbabe wrote:
| > I can almost guarantee that you're just at the wrong company.
|
| I can almost guarantee your company needs less of the wrong
| people. You need them to leave. So, ahem, talk to your network.
| DrBazza wrote:
| > I can almost guarantee that you're just at the wrong company.
|
| You're at the wrong company if you're unhappy regardless of the
| size.
|
| I've worked at a very small company which was miserable because
| the owner didn't have a clue and was only interested in the
| bottom line to the point of letting the software and the
| systems atrophy.
|
| I've worked at Megabank, and it was also miserable. Actually
| writing code probably ended up being a sum total of 3-4 hours a
| week. At best. Too many meetings. Absurd change control system.
| Crazy processes and sign off.
|
| And then there have been a few mid-sized companies - 20-200,
| and they've been the most fun. Get on with coding and even
| whilst managing a small team.
| LegitShady wrote:
| sometimes its not the wrong company but just the wrong team or
| even individual coworkers (I guess if you're in a company that
| has multiple teams).
|
| We had a new hire join a few years ago and every time they had
| a work task that they hadn't done before they'd make multiple
| meetings about their particular part of it, asking for advice
| in meetings instead of informal conversation, asking others to
| fill in documentation etc that might have been reasonable once
| or twice but essentially created a work by committee
| approach...to their work. It was exhausting and I let my
| manager know I was going to start declining their meetings semi
| regularly.
|
| When people started declining the volume of such requests and
| tasks suddenly dropped.
|
| But depending on how intractable your team or org, is, finding
| a new job may be easier.
| Trasmatta wrote:
| What are these unicorn companies? I've worked at 7 companies
| (and interviewed at many more) and never seen anything close to
| this mythical "company that values programming and real
| productivity". I feel like they must be exceptionally rare.
| ss108 wrote:
| How diverse have the companies you've worked at been in terms
| of size, etc?
|
| As a perhaps incomplete or shoddy heuristic, smaller startups
| tend to focus on productivity and moving fast.
| [deleted]
| Aeolun wrote:
| The only ones that I've found like that are the ones in which
| either the company, or the team, is led by a former/current
| programmer.
| kasey_junk wrote:
| I've worked at about 10 companies and half of them didn't
| have the soul sucking processes (though all of them did have
| process).
|
| The correlation I see is big companies have processes that
| kill productivity, though I did work for a big company that
| was able to avoid it for a long time (new leadership did end
| up killing productivity right before I left).
|
| And for what it's worth there was no correlation with
| "agile". I've seen good and bad agile.
| 411111111111111 wrote:
| The term unicorn in this context makes it hard to understand
| what you're asking, as unicorn companies are usually defined
| to be corporations with i believe a billion in revenue. This
| often comes with the usual downsides.
|
| Smallish companies often leave a lot more freedom for their
| developers, but you'll most likely also be missing a lot of
| things you've gotten used to (highly automated CI/CD, teams
| "responsible" for each part of the system etc)
| at_compile_time wrote:
| They're referring to the mythical animal, using a metaphor
| to express that such a company is mythical or non-existent.
| Coincidentally, this is same metaphor that the person who
| coined the term "unicorn company" was using.
|
| Given that private companies with over $1B in revenue
| actually exist while examples of "[companies] that values
| programming and real productivity" are yet to be
| forthcoming, the parent post is using the metaphor
| correctly and the finance world is not.
| jxramos wrote:
| I forget what job it was I was interviewing for but I remember
| being stunned at the open lack of process they had in place for
| trying to bother unifying all these teams to be on the same
| platform framework etc and instead deliberately let sub teams
| work with tooling that worked for them and didn't create a lot
| of overhead trying to coordinate and sync and share a common
| codebase. Every place prior to that day I had only heard of
| people going for long stretches to impose a company wide
| uniformity in tooling. All the costs associated with getting
| everyone on the same page was always taken as a worthy cost to
| pay and that future date in the promise land would have made it
| all worth it.
|
| The folks in this other company just flat out said not worth
| it, just get your stuff done, ideal development scenarios and
| perfect harmony and alignment have too much hidden costs to
| bother with.
|
| It's naturally a pro and con scenario but it was pretty
| refreshing to hear of folks so unconstrained by this self
| imposed constraint every other shop had imposed on themselves.
| bennyelv wrote:
| I work at a company that's trying to come out of the other
| side of this kind of approach. Let me tell you, it might feel
| good while you're doing it but in 5 years time it will be a
| hot mess of unmaintainable garbage! There are hidden costs in
| trying to align as you go, but there are potentially company
| ending costs in not.
|
| You're right that there is no promised land, but the quest to
| reach it prevents you regressing into hell.
| hn_user2 wrote:
| I have seen two extremes of this. The one side is forced
| conformity, and the other side was complete chaos. To the
| point where each project was written in its own language.
| Imagine changing teams to help on a project and step 1 is to
| learn a new language and deploy methods.
|
| I feel like there is a golden middle where the team has
| decided on maybe 3 languages, one typed, one scripted, one
| cutting edge. And a few different deploy scenarios, and you
| can pick amongst them.
| karaterobot wrote:
| I dunno, I think OP may be right. I was in the same boat: I
| thought I hated programming, then one day I realized I just
| hated the industry wrapper around it. I recognize some of that
| process stuff can be valuable, but it's hard to disentangle the
| good stuff from the trash. Much of it is cargo cult, article-
| driven thinking that does nobody any good. A few years ago I
| switched to design, and now I just program in my spare time for
| fun. And it is fun when you do it right.
| soneca wrote:
| I agree and I would suggest trying small companies or very
| early stage startups (with less than 10 Software developers).
| You get to program a lo, but not all goods though. A lot of
| context change and you have to also think about product and
| design, so it's not just programming. Also the risk of the
| company not existing in a year. But, for me, it's perfect.
| jensensbutton wrote:
| > Find a company that values programming and real productivity
|
| What's an example of a company that values "programming" over
| the business?
| jabedude wrote:
| Isn't google the canonical example?
| jensensbutton wrote:
| I've been a manager at Google. It is not the canonical
| example
| anotheracctfo wrote:
| Valve. They're kind of dysfunctional from what I hear.
| gumby wrote:
| A company that values programming over its business won't
| stay around long (see the recent front page submission called
| something like "your stack is not your product"). Sales is
| what covers payroll.
|
| _However_ a company that values programming over managing
| will prosper more than a company that values managing more
| than programming. Just enough management that everybody knows
| they 're working on the right thing is best for all
| (including the managers).
|
| Process for its own sake (I'm looking particularly at cargo-
| culting "agile" astronauts) sucks the life out of everybody
| involved.
| casey2 wrote:
| These processes exist for a reason, even if nobody knows what
| it is. Over time companies that did these things survived,
| maybe nowadays it is vestigial, but the burden of proof is on
| new successful companies that don't have these practices.
| mobiuscog wrote:
| I think it's more marketing and profiteering based on
| correlation over causation.
|
| Almost every process these days is bought in by a new
| managerial hire, or after attending an event, where a talk or
| book that shows X companies that are very successful all
| followed the Y practice, and so 'we should too' as it's
| obviously the path to success. Rarely is there reflection on
| whether the process is working, and blame is laid at the feet
| of the workers.
|
| Despite many recollections and experiences retold about how
| processes may not work, they are silenced by the advocates of
| such processes who will show how successful they were (and
| also just happen to make their living by advocating rather
| than actually being on the ground).
| lloydatkinson wrote:
| I concur, I even wrote this down as I found it therapeutic.
| https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what...
| ok_dad wrote:
| I am here to say that both "too much" and "too little" process
| are shitty. I have been at companies with too much process
| (medical devices) and companies with WAY to little process, and
| both places are an absolute nightmare. What you want is a
| process that ensures features are spec'ed out properly, testing
| is performed, deployment is smooth, and etc., with a lot less
| or zero of the "put your hours into the Jira ticket" type
| bullshit.
| wpietri wrote:
| Tastes differ, as do circumstances, but the last place I want
| to work is one where things are spec'd out "properly". For me
| one of the great sources of joy in making software is jointly
| discovering needs by exploring the problem space. I've done
| whole companies with nothing more than index cards, napkin-
| quality sketches, and very close team relationships. I love
| it.
| ok_dad wrote:
| That's fine until half or more of the team moves on, then
| you have a spaghetti mess that newcomers have to theorize
| about and clean up.
| wpietri wrote:
| I'm talking about product design, not technical design.
| But I don't think specifications help in the long term
| there, either. I think the way you get designs that are
| understood by both old-timers and newcomers is continuous
| improvement of the code through refactoring and cleanup.
| ok_dad wrote:
| > I'm talking about product design, not technical design.
|
| Even worse!
| wpietri wrote:
| Ok? I'm telling you I have done it and it works well. If
| all you want to do is squawk about it, I guess I'll make
| my exit here.
| davidw wrote:
| I think the real "unicorns" are
|
| * Small/medium size companies where you recognize most everyone
| even if you don't work with them. There are enough people so
| you don't have to do things you're not qualified for like in
| the very early days of a startup.
|
| * Steady growth, but not crazy, venture fueled moonshots.
|
| * Selling something that earns enough money to grow the
| business in a fairly organic way.
|
| I worked in a place like that once and loved it, and did some
| of my best work there. I wasn't anxious that it would implode
| like a startup, and there wasn't much bureaucracy.
| mulmen wrote:
| I worked in a place like that and it was awesome.
| Unfortunately we were so good at what we did across the board
| that we got bought by another company to integrate into their
| larger offering. It made a lot of sense from a business
| perspective but the tech team in our office was made
| redundant and so my time there came to an end. I think this
| is the inevitable conclusion to good, small companies. Since
| it actually works they will eventually get swallowed by a
| larger fish who rightly identifies them as a tasty morsel.
| notnaut wrote:
| Did you at least reap some of the buyout benefits?
| TranquilMarmot wrote:
| I was going to say the same thing. Worked at a mid-sized
| startup, great culture, amazing coworkers that I'm still
| friends with today. We did great work and got bought out by
| a large company who had promised not to mess with our
| culture too much. That didn't last very long haha
| cutemonster wrote:
| > mess with our culture
|
| What did they change/do? If I may ask
| Aeolun wrote:
| Is it really that hard for owners to resist the alure of a
| buyout? I dunno, I always like to think that I'd continue
| doing the good thing that I've got going.
| __pache__ wrote:
| You try dealing with everyone's problems and hitting all
| the deadlines all the time..!
| nunez wrote:
| If you don't, your successor will. Money makes the world
| go round.
| yafbum wrote:
| Sometimes you're kind of forced into it: if your growth
| starts taking off faster than you thought, you may be in
| need of more capital just to stay in business. At that
| point you have a choice: slam the brakes (turn down
| customers), borrow (risky), raise (dilutes you), or sell
| out. If you can find a solid working relationship within
| the acquirer's company, all is good...
| phkahler wrote:
| There is actually nothing wrong with turning down
| business. No need to grow faster than you can handle. A
| company in the situation you describe is doing something
| very right, so maintaining that seems like a good
| strategy.
| 1123581321 wrote:
| There is nothing wrong with it, but it's hard to do
| skillfully, especially in the chaos generated by rapid
| growth, and you may not realize the need until you're
| already trapped by your existing commitments. Good
| relationships in the company can fall apart in the
| decision-making, too (e.g. if someone's personal/career
| growth path is cut off by the decision to stop pursing
| something that's been built towards for years.)
|
| Some types of businesses can do it more easily than
| others. Professional services can probably do it the
| easiest. A B2C business with a turnkey offering could
| have a lot of trouble paring back, especially if the
| product has a physical aspect.
| yafbum wrote:
| For an entrepreneur who set out to fix a problem in the
| world, it can feel very wrong not to give customers the
| solution that you know you can give them, for mere
| capital reasons.
| dzikimarian wrote:
| Try reversing this argument and talk about employee
| resisting much better offer, to remain loyal and you'll
| get eaten alive by commenters :-)
| TheOtherHobbes wrote:
| The two aren't unrelated. In the distant past companies
| had professional and personal development programs. Some
| even had a commitment to try to avoid layoffs.
|
| When MBA culture took over in the 80s it became normal
| for companies to act like extraction machines. Employee
| loyalty crashed, with a corresponding increase in churn.
|
| Taking investment money makes it hard to create a humane
| culture. But smaller private companies do at least have
| the option to consider it.
| Aeolun wrote:
| Is that so? I see a lot of people not wanting to switch
| for solely more money because they expect to hate it at a
| potential new company.
| dzikimarian wrote:
| Yes and the same works for founders. If they expect, they
| will hate it after buyout, they will probably resist.
|
| But what if new opportunity is ok, gets you 30% more
| money, but your departure makes your current company very
| sad and perhaps worse place for everyone to work at?
|
| I wouldn't expect a lot of support for the idea of
| staying if you ask the internet for an opinion.
| andrewflnr wrote:
| I really don't want to believe everyone has a price,
| since that would mean I have one, but the evidence offers
| very few if any solid counterexamples.
| lazyasciiart wrote:
| If it gets that much bigger you (the owner) probably
| _aren 't_ doing the same thing you were doing.
| dudus wrote:
| The Peter Principle also applies to teams and companies.
| tluyben2 wrote:
| Same here. Got absorbed and it killed everything good about
| the place.
| thrdbndndn wrote:
| Just curious: why you didn't work there anymore?
| davidw wrote:
| Moved halfway around the world. That company is still doing
| well from what I can see.
| itake wrote:
| I've worked at 3-4 small companies (less than 30 employees)
| and I've never been happy. There is always 1 person that
| makes my life miserable (constantly rejecting my ideas, ego
| is larger than their experience level, etc). I've worked at a
| 100, and two 1,000 engineer count companies and I never met
| any "coding princesses" in those roles.
|
| I think part of the problem that triggers this is in small
| companies, one engineer codes, a significant portion of the
| code base and has a strict vision in their mind about how
| that code should be structured. When new employees come in to
| bring new ideas, they become personally offended that their
| baby is no longer their baby. At large companies no one feels
| like they own 100% of the code, and each change is very
| collaborative.
| ricardobayes wrote:
| Are you ideas normally implementable in the next month or
| something far-fetched? Try to come up with ideas that are
| low hanging fruits, easy to do but have a high value. I
| don't think any company/management in their right mind
| would constantly reject "good" ideas that ultimately result
| in more revenue. The ideas I see being rejected are either
| too far out there or some "dev utopia"-kind of ideas that
| don't bring in more cash, just burn effort.
| ornornor wrote:
| > I don't think any company/management in their right
| mind would constantly reject "good" ideas that ultimately
| result in more revenue.
|
| We must have worked at _very_ different places.
| itake wrote:
| The problem is there are many ways to implement a
| feature. Often one isn't objectively better or worse than
| the other (but subjectively it is).
|
| Everyone wants the problem solved, but how the problem is
| solved leads to frustration.
| madeofpalk wrote:
| > I've worked at 3-4 small companies (less than 30
| employees)
|
| What I vastly prefer is the 500-ish size. You can
| realistically at least know of every other developer (and
| find those you prefer working with and can learn with),
| there's more resources than just a 30 person company, and
| you're just not a tiny insignificant cog in the machine at
| a 100k mega corp.
| roland35 wrote:
| It really depends what team you're on! My little corner
| of megacorp is fast, pretty lean, and I definitely feel
| like I am able to make an impact on our product (which is
| a smaller product in the company). I feel much better
| here than at some of the mid size companies where I felt
| there was a low ceiling on growth opportunities.
| luisapic wrote:
| [flagged]
| electrondood wrote:
| 200-400 is the sweet spot, I've found.
| davidw wrote:
| Yeah I could see that. The place in question where I worked
| was developing some new products, so we didn't have that
| kind of situation where someone was gatekeeping or
| otherwise being unpleasant.
| jonas21 wrote:
| > _At large companies no one feels like they own 100% of
| the code, and each change is very collaborative._
|
| That's how you end up with endless process, design by
| committee, and having a dozen meetings with all
| "stakeholders" before actually writing any code.
|
| I'd much rather work at a place where individuals or small
| groups have a strong vision on the code and product and are
| capable on executing independently on that. It sounds like
| the OP would too. But I understand it's a personal
| preference.
| themitigating wrote:
| "I'd much rather work at a place where individuals or
| small groups have a strong vision on the code and product
| and are capable on executing independently on that"
|
| Isn't that dependent on whether you are the person
| guiding the code though?
| Tcepsa wrote:
| Honestly, not necessarily--there are often many ways to
| solve a given software problem. If someone else has a
| vision for the software and a plan to achieve it as a
| team, as long as I can see that it is looks like a viable
| alternative I'm generally happy to go along with it. Far
| better than flapping in the breeze with nobody providing
| clear guidance or input, in my opinion!
| Viliam1234 wrote:
| > But I understand it's a personal preference.
|
| Indeed. No company size is perfect. There are
| dysfunctions typical for small companies. There are
| dysfunctions typical for large ones.
|
| But people have preferences; some things they can handle,
| other things drive them crazy. What drives you crazy may
| be different from what drives your friends crazy.
|
| Perhaps everyone should try to work once in a large
| corporation, and once in a startup, to figure out their
| own preferences.
| davidw wrote:
| I read something about how a lot of 'super group' bands
| kind of don't do anything truly great because of this
| type of dynamic. They all know they're good, they know
| the others are good, and they all have a bit of an ego
| and don't want to stomp on the others, so they all tend
| to "go along with it" without getting too pushy. That
| leads to good, but not great music.
| granshaw wrote:
| Enterprise software is not art and shouldn't be
| approached the same way. You want a roller-coaster-like
| experience, go join a startup
| davidw wrote:
| No one said 'roller coaster'. Part of quality software is
| saying 'no' to stuff, or having a coherent vision, not
| 'software by committee'.
| Aeolun wrote:
| Only if you have a quality engineer at the wheel though.
| Otherwise you just end up with horrible software.
|
| I guess that's why large enterprises hate it, since
| they're all about reducing risk.
|
| If they get middling software every time then that's
| preferable to the two extremes.
| rintakumpu wrote:
| Definitely. Though there are exceptions. Led Zeppelin
| comes to mind first.
| davidw wrote:
| I think part of the idea was that in an actual band that
| has been a band for a while, they usually find a way of
| working together that includes "difficult conversations"
| and saying no, and sometimes listening to one person's
| vision rather than tiptoeing around egos.
| RHSman2 wrote:
| This is the long term way to greatness. In companies and
| life.
| [deleted]
| slaymaker1907 wrote:
| Oh, I've definitely met princesses at large companies,
| though you are spot on about the ownership issues. The
| problem really isn't the size of the company but how siloed
| the code is.
| itake wrote:
| Yeah, one of the 1000-person companies had a dev whole-
| own a critical microservice. Changing it was always a
| battle, because the owner was very critical of anyone
| touching 'his' service. Large companies aren't immune,
| but due to eng specs and collaboration baked into
| development, its less likely for this to happen.
| makestuff wrote:
| The downside is a significant comp reduction unless it is
| some sort of trading/hedge fund.
| kirso wrote:
| So much this.
|
| After 14 years in a workforce, my happiest moments were in
| software SMB (joined at 10 people and left at around 100).
|
| Never felt like work. We were just building something cool
| together as a team on the same page.
|
| Turned profitable after Series A and never raised again.
|
| Later down the road I realised that these are the real
| unicorns once I actually landed in terrible jobs or
| corporates and how disengaged everyone is in the legacy
| organisations. Was genuinely shocked that these companies
| don't go out of business.
|
| I am now trying to collate the list of companies which fit
| the criteria above but it's really hard.
| stitched2gethr wrote:
| Seconded. And might I suggest a smaller company. Smaller
| companies (like startups) are about about solving the problems
| at hand quickly. As companies grow there is a larger risk that
| any one mistake can lose the company money, which will
| generally continue to flow if they do nothing, and so they
| intentionally put in a lot of road blocks.
| [deleted]
| inglor wrote:
| It might even be very different in the same company. I changed
| teams in my large company and the number of recurring meetings
| around process dropped from 8 to 0, no more daily, no sprint
| planning etc - we just talk about the feature then do it and we
| don't need a lot of process since communication works well
| anyway.
| datavirtue wrote:
| I love meeting with the right people, documenting my work, and
| working with legacy code. Especially meetings, nothing more
| invigorating than building something with a team.
|
| That said, as some have already mentioned, all of this is
| typically ruined somehow at nearly every company.
| onehair wrote:
| I dislike working just as a "software engineer" in a team where
| my part in decision making on the product progression isn't
| very significant. I like programming and tinkering with
| everything in the computer science domain because it's so very
| thrilling and rewarding.
| yellowapple wrote:
| > I can almost guarantee that you're just at the wrong company.
|
| The trick is finding a company that's not wrong.
|
| Early-stage startups typically qualify, but they're also
| typically short-lived; they usually either go under or else
| grow into the same sort of "wrong company" one's trying to
| avoid.
|
| A small business that's been around awhile, with a stable
| customer base and no ambitions for growth, is probably ideal -
| but good luck getting such a company to hire you. You _might_
| have better luck picking up multiple such companies as an
| independent consultant.
|
| A different ideal (or so I've found) would be a company that's
| large but dysfunctional, or to be an "analyst" or somesuch in a
| department that's sufficiently large and autonomous to get away
| with having "shadow IT" (and a lax enough corporate IT
| department to not interfere).
| kodah wrote:
| Agreed, this sounds like OP is in the wrong job. To me, there
| are two types of companies as an engineer. There are companies
| that like engineers to focus solely on product. This is the
| kind of company you'll hear "don't reinvent the wheel" a lot at
| because their understanding of their core skills probably
| doesn't branch that deep into engineering. Then there's
| companies where engineering is core to the product. Some folks
| hate these kinds of companies, but I tend to enjoy them because
| even the niche networking stack is related to product delivery
| somehow.
|
| Product-focused companies also, in my experience, tend to put a
| lot more emphasis on ritual precision. Agile isn't just a means
| of organizing, it becomes _the way_ you get things done. These
| companies also tend to have some culty vibes to them, but
| again, could just be my experience. At engineering focused
| companies I 've "done Agile" but the emphasis was mainly on
| giving me tools, systems, and incentives to self-organize more
| than the rituals themselves. These kind of companies are
| actually where I learned to love testing a lot more than I used
| to, but that was because someone took the time to shape how I
| wrote code so that it was easy to test.
| x0x0 wrote:
| It could also be the wrong tools.
|
| eg I like having tests, and I like writing them, because they
| make my life better. But the contrast between the effort
| level to write tests in ruby or python vs go... I hate go, I
| hate the lack of good mock support, and I dislike writing
| tests at work because I hate go.
| flashgordon wrote:
| "wrong companies" is it. Perhaps it is love software
| engineering AND coding but hate big software companies?
|
| Also with "some software companies can turn even the
| simplest..." You may have forgotten to add "and add metrics to
| these rituals as performance goals"!
| jstx1 wrote:
| Not enough process can be a pain too. "Just do this for us"
| without specific requirements, and then the thing you've built
| is never good enough and needs to be continually refined anyway
| or it's never used. Those environments are also soul crushing,
| just in a different way from the ones with too much process.
| snowstormsun wrote:
| assuming the process actually includes proper specification
| of work
| Kamq wrote:
| You're assuming they're mutually exclusive.
|
| I've had all of the ceremonies and no AC on plenty of
| tickets.
| Aeolun wrote:
| I consider "Getting the requirements to be versioned on
| Confluence instead of with a large sequence of excel files"
| to be one of my big achievements. And I hate Confluence with
| a passion.
| xyst wrote:
| > Some software companies can turn even the simplest tasks into
| a grueling series of processes, endless meetings, and joint
| work across a big number of "stakeholders". These companies
| will take the joy and productivity out of programming and
| replace it with a series of rituals and set of language that
| people use to go through the motions every week so they can
| collect paychecks.
|
| god - this is so true at my last company. Any attempts to
| decrease meetings, remove unnecessary process are met with
| heavy resistance. Getting shit done was nearly impossible.
| People had no responsibility for their work. Only wanted
| "stories" and "subtasks" assigned to them. Doesn't matter if
| the story was trash/useless/no-op, they just wanted it to pump
| their numbers because the quarter is ending. I shouldn't have
| tried so hard to make changes. They probably ended up getting
| reverted by the next person or manager.
|
| Pro tip: if the company you joined tends to hire new people
| then retain them. Then fucking run. During the first "all
| hands" in that company, nearly 80% of people that worked in the
| organization were hired in the past 1 year or so. It ticked
| "red flags" at the time but I ignored it because honestly I
| needed the money at the time (just graduated college)
| __MatrixMan__ wrote:
| I'm confused. Aren't all companies that got a round of
| funding ~1 yr ago going to have a large cohort of <1 yr
| tenure employees? What connects this to death-by-process?
| g051051 wrote:
| > I am not too keen on learning new paradigms or languages unless
| I have to.
|
| Not the attitude I'd expect from someone that claims to "love
| programming".
| quicklime wrote:
| People will disagree with me here, and at the end of the day I
| might just be getting hung up on semantics. But I don't think
| that the processes that come with sprints and agile are what
| change it from being "just programming" into "software
| engineering".
|
| I took this off of the Wikipedia article for "Engineering", but
| pretty much every definition I've seen says something like this:
|
| > Engineering is the use of scientific principles to design and
| build machines, structures, and other items, including bridges,
| tunnels, roads, vehicles, and buildings
|
| So if you're using _scientific principles_ , i.e. you apply
| knowledge from sub-fields of computer science such as distributed
| systems or cryptography, then you're doing software engineering.
| Sometimes this is important, e.g. you need to understand how a
| system will scale under load if it is used by a large number of
| users. Other times it's not so important.
|
| But all that agile process stuff? That's not science, nor
| software engineering - it's just project management. Sometimes
| project management is important, such as when you need to
| coordinate large groups of people, or manage delivery risks. But
| in my (probably overly) cynical opinion, Agile (in practice, big
| A, etc) is usually just a heavy-handed way for companies to
| micro-manage under-performing teams - and at least for me, this
| is the biggest thing that just completely sucks the joy out of
| programming.
|
| > What are some good jobs for a person like this?
|
| So given the above, I'd suggest seeking out companies that are
| working on interesting problems that require computer science
| principles to be applied, rather than just another enterprise
| CRUD app where the hardest part is dealing with the business
| stakeholders.
|
| And avoid companies that require a lot of project management -
| places where every bit of work requires coordinating a larger
| number of people than you would normally think necessary. This is
| most big companies, but also a lot of small companies too.
|
| Unfortunately, this takes a lot of jobs off the table. But if
| you're able to find something that fits you, that's a great
| result.
| faangiq wrote:
| I like both those things. I hate people.
| tombarys wrote:
| My solution: I am a book publisher (age 50, 25 years in
| publishing). But during my life I found that I deeply love
| programming too in a way you mentioned - solving problems. Small,
| private conundrums. Sometimes creating simple apps. But just as a
| hobby!
|
| If I had to make money by coding, this all would be gone.
|
| So: do another job and code for fun. :)
| dmarlow wrote:
| Ha, I'd say rearchitecting is fun and incident response is not
| fun.
|
| I think there are parts of the process that people enjoy over
| others and that's based on many factors, personality, company
| culture, managers, coworkers, process and tooling, etc.
|
| You don't have to enjoy every aspect of it. Just like enjoying
| cooking, and not enjoying doing the dishes.
|
| The important part is being professional, doing what's asked, not
| being negative about it, and look for opportunities to improve
| that part of it.
| ambientlight wrote:
| For me it is usually quite the opposite somehow
| wintorez wrote:
| It depends on how do you define software engineering? For me,
| software engineering is what allows us to do programming on
| scale. Programming is sure fun, but on its own, its very hard to
| scale beyond one person. If you want to distribute and delegate
| tasks, you'd need software engineering.
| ShreyJ wrote:
| My comment on this article.
| vinaypai wrote:
| To be completely honest it sounds like being a trust fund baby is
| the right "job" for you.
|
| It sounds like you just want to stay in your comfort zone, not do
| anything that your don't consider "fun", and don't want to learn
| anything you're not comfortable with, and don't want to think
| about the future or any of the rest of your company.
| dislikedtom2 wrote:
| I love fishing but could never be a fisherman. Jobs are not fun,
| but more like temporary slavery.
| cca778 wrote:
| Do you hate catering but love cooking?
| the_only_law wrote:
| More like I love cooking but I hate cooking shitty boring fast
| food I'd never eat myself.
| worik wrote:
| Slightly off topic but my pet peeve is most people who call
| themselves "Software Engineers" are _not_ engineers. They have
| not studied any engineering at all
|
| There was a fashion for a while to call people "Software
| Architects". I do not know what happened to it but I fantasise
| that some architect society got busy and put a stop to it.
|
| I am a computer programmer. I do things that "software engineers"
| do, but I do not lie about my qualifications, which are all in
| science and commerce.
|
| Computer programming is a noble craft, we do not have to put on
| airs.
| wnolens wrote:
| Liking software but hating software engineering is kind of like
| enjoying the platonic and hating reality.
|
| We're all in agreement that the real world is messy and stressful
| to deal with. That's life!
| kaashmonee wrote:
| But I think that's what truly makes it "engineering." Programming
| and solving problems are fun in a vacuum but tech is just a lot
| more than that. Being able to produce a solution to a problem
| today doesn't mean that the same solution will work tomorrow.
| That's why we have to _engineer_ a solution, not just produce
| one.
|
| I'd argue this is true of any engineering discipline. For example
| consider this analogy: we build bridges to solve the problem of
| being unable to cross to the other side. But we could also solve
| this with, say, a boat, to paddle ourselves across the body of
| water instead; in fact, that's a much more immediate solution
| that solves the exact same problem. But is it sustainable? Is it
| scalable? Can it handle traffic? To address these concerns, we
| _engineer_ a bridge.
|
| Software that's meant to service a lot of people can't just be
| written to solve a particular problem today -- it must be
| _engineered_ so that it's future-proof, which is to say, easy to
| scale, easy to read, easy to refactor, etc. So often the simplest
| programming challenges become particularly difficult and often
| interesting engineering challenges.
|
| Finally, to actually answer your question, it entirely depends on
| the company, the size of the team, and the commitment to code
| quality and engineering that that team has. Working at Google on
| the search team, for example, wouldn't be a great fit for you
| because every line of code you write has to be engineered! But
| working at a startup might.
|
| But this comes with tradeoffs. Often times, the solution you
| write will have to be rewritten if you want your product to
| succeed. Refactoring and re-architecting things are a necessary
| evil as technology, hardware, and languages + frameworks change
| over time. I've worked at places where I've found myself
| repeatedly having to work on the same things over and over again
| because of how poorly engineered they are! If you enjoy
| programming and solving new problems and you want to have a
| career doing that where presumably you're building some sort of
| product, you have to engineer at least somewhat reasonable
| solutions today so that you can work on something new, exciting,
| and cool tomorrow.
| yashap wrote:
| Sounds like you should join an early stage startup - like 5-15
| people in the whole company. There will be lots of rapid
| development of new features, lots of outages, and minimal
| process. There will still be some refactoring/rearchitecting, but
| with a lot less code and a lot less users you can do it a lot
| faster.
|
| You could also consider agency work. There will be more process,
| a lot more checking in with stakeholders, but you'll build a wide
| variety of greenfield projects, and sounds like that's important
| to you.
| mclightning wrote:
| Programming can be many things. I don't particularly appreciate
| finding or fixing bugs, or unit tests, incidence response. Very
| rare breed of programmers do these for a hobby. But you know what
| many more people program/code for a hobby? Games, graphics
| development. I love that shit.
| irrational wrote:
| Devops is what I hate.
| mkl95 wrote:
| Software engineering != feature factories, bodyshops, most big
| tech and mid tech projects, etc. There are not so many people
| consistently doing software _engineering_.
| amackera wrote:
| What does Software Engineering actually mean then?
| mkl95 wrote:
| The use of scientific principles to design and build
| software.
| Annatar wrote:
| [dead]
| sasakrsmanovic2 wrote:
| RE: Finding and fixing bugs is a lot of fun
|
| In that case I suggest finding a commercially-backed, open source
| project which you are passionate about. You can have best of both
| worlds - plenty of bugs and community interaction, all while also
| making a living out of it.
| [deleted]
| asah wrote:
| After 35 years, software engineering remains a moderate challenge
| but programming is no longer interesting.
| retrocryptid wrote:
| I'm a little different... I love programming and am "okay" with
| software engineering. But my first several years coding were in
| Lisp, so I developed an idiosyncratic style, and have to "tone
| down the lispiness" when coding with other people. I enjoy
| working w/ other people, but would love it if there were more
| people who's brains were twisted the same way mine is.
| jlarocco wrote:
| It's a little unclear what you actually "hate" here. To me,
| refactoring, rewriting, and rearchitecting are very different
| things than sprints, agile, and all that process.
|
| If you hate the process, then it's probably easiest to find
| another job with process you can tolerate - especially if the
| current process is working for your company. If enough people are
| frustrated by it you may have some luck getting the company to
| introduce a new process, but I'd expect an uphill battle.
|
| If it's really software engineering and architecture that bothers
| you, though, I'd strongly suggest giving it another try. "Making
| something that just works" now, is awesome when you're writing
| the code in the first place, but it's an absolute maintenance
| nightmare, and it won't be long before you're drowning in tech
| debt.
|
| A whole team where everybody says "lets just do the first thing
| that works" may work for a treehouse or a shed, but you'll never
| build a skyscraper or big project that way.
| cjfd wrote:
| Find a job where you can work alone on something, maybe. Working
| alone removes much hassle. You also list 'refactoring' as
| something that you don't like. This will be part of any
| programming job as soon as it outgrows 'hello world' by only a
| small amount. Furthermore, you list 'agile' as something you
| don't like. Originally 'agile' was intended as being able to
| respond quickly to changing wishes from the users, not as all of
| the (in)famous 'agile' ceremonies. If you also want to remove the
| former from the equation, you limit yourself even further and I
| think it would be hard to get a job that satisfies all of those
| demands.
| matt_s wrote:
| The process that comes with it is there to organize the work and
| align it with the organization's goals. It can be agile, kanban,
| waterfall with big upfront design, it doesn't really matter what
| methodology is used, its there to organize the work. For large
| and/or existing systems, without that glue there would be
| programmers running amok solving problems they like to solve with
| whatever shiny things they want to use. I'm sure without
| guardrails there are a lot of engineers that would re-write all
| the code they didn't like, building their own bike sheds all over
| the place.
|
| Sounds like maybe startups would be your jam. Not a lot of legacy
| stuff to work on, lots of bouncing around to different types of
| tasks, shit breaks a lot, etc.
|
| The other idea is more of devops/systems stuff working with the
| cloud. Lots of solving problems with code (orchestrating cloud
| resources w/code) with not a lot of Project Manager overhead in
| the right environment. Lot of incident response.
| ResearchCode wrote:
| That's called code review, you don't need any "agile" for it.
| Agile is used to micromanage engineers to push out crap
| features, optimizing for the two week return, with poor results
| in the longer term. The people running amok are layman "agile
| coaches", "business analysts" and "product owners". While poor
| engineers are prevented from doing necessary non-feature work.
| matt_s wrote:
| You can get benefits from small-a agile in the sense of
| organizing the work in small chunks that can be put into
| production when ready using CI/CD. If done right, you end up
| not doing work on things that aren't needed vs. in a
| waterfall model with large specification docs you end up with
| feature bloat in a product. Forced two-week cadence and
| preventing non-feature work indicates poor management.
|
| I don't like SiverBulletCo coming in with tools and trainings
| and This Is The Only Way(tm) bullshit either. Maybe lean
| development is a better wording than agile? Its more about
| small work chunks and deploying them when ready vs months
| long projects with Gantt charts. Kanban seems to be the best
| way to organize work to me. However, letting a team of people
| align on what process they want to use with what makes sense
| plucking concepts from agile is fine.
| cratermoon wrote:
| > Agile is used to micromanage engineers to push out crap
| features, optimizing for the two week return, with poor
| results in the longer term
|
| More correctly, organizations micromanage engineers to push
| out crap features, optimizing for the two week return, with
| poor results in the longer term, and call it 'agile'. They
| wouldn't know the nature agile if it fell on their heads.
| t43562 wrote:
| It's hard to be helpful because I find this a bit like saying "I
| want a job where I can cook cool new food but not do the washing
| up."
|
| You're more likely to get this being a contractor or at a small
| company. Most of it's going to be a matter of asking the right
| questions though - you probably want to have some well defined
| area of responsibility and not have to work with anyone else in
| it.
| capitanazo77 wrote:
| I prefer many small projects than big ones. Because complexity
| grows exponentially but payment and fun don't
| kovac wrote:
| Not just you. Software development, especially web, is a very
| pretentious industry. I believe that itll be one of the first
| programming jobs that'll fall to AI if it happens someday (no,
| systen architecture is not some special, difficult skill only
| some of us can have as they'd have you believe). Embedded, OS,
| scientific programming, they do real work there.
|
| Take a magazine like POC||GTFO and see what real engineering
| looks like. Recently I came across a nice challenge there to
| write a program for which the compiled binary must be a
| palindrome. Good stuff. If you can afford, switch to something
| like embedded development. You'll probably make less in the short
| term but you'll get to keep your soul.
| ccday wrote:
| Binary palindromes are real engineering, Google Search is not?
| Pretension indeed.
| kovac wrote:
| Are you saying that Google search is representative of most
| of the Web applications/rest APIs developed today?
| luisapic wrote:
| I want to fuse myself in your feet, to block all the steps
| of creatures, and so repair for them and give your steps to
| all, to make them walk in a saintly way.
| moris_borris wrote:
| Not an answer to your question, but some perspective from my own
| experience.
|
| I worked with a bunch of people like yourself at a fast-paced
| adtech startup. Clean code and even sustainability were not a
| priority, and the company had a money printer in the basement.
| Has the front-end gotten so messy it's unmaintainable? No
| problem, let's make a new one from scratch! I loved that we were
| given so much time to solve interesting problems with bleeding-
| edge tech, but I hated the filth of the code, particularly trying
| to read other hackers' code. And yes, so extreme was the priority
| of haste that these engineers were more hackers than anything
| else. That wasn't really my style, so I left.
|
| Now I work with people who are the opposite. They love fussing
| about the `describe` blocks in their unit tests, will draw up
| Excel sheets to supplement the JIRA board, and spend an afternoon
| arguing about whether that 100% test coverage is really covering
| all functionality. The codebase is a textbook of how to write
| beautifully maintainable, readable code. Pull requests are
| genuinely enjoyable. But ask them to learn a technology from the
| last 8 years and they just start refining their refactoring
| tickets.
|
| Perhaps I will find a happy medium between these two extremes.
| ChrisMarshallNY wrote:
| I tend to like engineering, but that's because I'm sort of a
| completionist. I like _finishing_ stuff. I like getting to the
| point where I no longer have to worry about it, and I do a good
| job, the first time, so I no longer have to worry about it.
|
| I like to F^3: Finite, Focused, and Finished: -
| Finite: I know what "done" looks like. Tasks have a discrete
| beginning and end, though the schedule may be fuzzy.
| - Focused: No distractions. I stay on beam, and devote full
| attention to the task at hand. - Finished: I don't
| stop, until I have reached a point that I can wrap things. I
| usually punctuate this with a final tagged commit.
|
| I've come to realize that this is kind of an aberration.
|
| I cover it, in a way, in this post:
| https://littlegreenviper.com/miscellany/thats-not-what-ships...
| duringwork12 wrote:
| This is me. Sadly I switched roles into a people code by their
| pants and projects sometimes ship type of company and now I'm
| on existential pain every day.
| fnordpiglet wrote:
| Back in the day agile was meant to let you program more. Then the
| process people came in and made it a tedious monstrosity. Then
| the management came in and made it unbearably oppressive.
|
| We need a reboot and a flight back to utility. But it was so hard
| to pull off in the 90's, I'm worried we never will recapture
| software development from the people who hate to program.
| JohnBooty wrote:
| Does _anybody_ enjoy the boring, non-programming bits of software
| engineering?
|
| I look at it like professional sports. There's a saying: _you 're
| paid to practice, 'cause the actual games are fun._
|
| That's the way I look at it. I'd write code for free, more or
| less. My employer is paying me for all the other crap I slog
| through: gnarly legacy code, weird bugs, endless meetings, etc.
| andrewstuart wrote:
| How can a stifling, boring software engineering process be
| changed into a fun programming process?
|
| This is a question that came up a number of times when I worked
| at a company where the developers were not enjoying working
| there.
| impulser_ wrote:
| I would suggest looking for software engineering jobs outside of
| SV (if that where you are and can) and outside the software
| industry.
|
| The best thing I did in my career was move the hell out of SV and
| started working for a manufactoring company building internal
| tools, scripts and programs.
|
| It will be hard to find the perfect job, but you will probably
| have a better chance outside of SV where every company tends to
| be a copy of one other internally.
| Barrin92 wrote:
| Rearchitecing and higher level system design are some of my
| favorite things. I really like thinking about big software
| systems. I also enjoy programming and implementation quite a lot.
|
| The one thing that's getting more and more prominent that really
| hounds me is DevOps, tooling and deployment related stuff. Be it
| containerization, credentials, complicated toolchains and dev
| environment setup, I absolutely hate how convoluted all of this
| has become and how little anything of it has to do with the
| actual software you're supposed to build.
| loxs wrote:
| I am the opposite. With time I have grown to be rather neutral
| and maybe slightly negative on the topic of programming and CS,
| but I love solving real-world problems and producing working
| solutions. I am content with having to program in order to do
| that, but would definitely skip the programming step if I could.
| robswc wrote:
| I'm the opposite, haha. I guess that's what makes good teams tho!
| stcroixx wrote:
| I hear ya. Agile really made working in software unpleasant. I
| long for the time the team had a simple spreadsheet of items to
| work on. So much more efficient.
| giraffe_lady wrote:
| I think I'm the opposite. I like solving problems as part of a
| team, evaluating different tradeoffs and approaches, figuring out
| what people need from the software and how to get it there as
| simply and cheaply as possible. It's very engaging with no easily
| identifiable "best" or "optimal" in most cases.
|
| Actually dealing with code is a pain in the ass. It's better than
| digging a ditch for ten hours a day but not really enjoyable for
| its own sake either.
| jackpeterfletch wrote:
| And thats great.
|
| The best functioning teams mix a set of people, with a diverse
| set of qualities, quirks, interests and disinterests.
|
| And work to accommodate them all.
| epolanski wrote:
| I actually prefer software engineering to pure coding.
|
| Pure coding honestly is boring after many years. There's a
| limited amount of times I can write code that listens to some
| event, manipulates data and passes it eventually to some api.
|
| Doesn't matter if it's augmented reality, databases, cli tools,
| it's always the same thing.
|
| On the other hand I find much more interesting setting up
| projects, their DX, their architecture, solving clients/customers
| problems under limited time and budget constrains.
| captainredbeard wrote:
| Refactoring is so much fun, get outta here
| ResearchCode wrote:
| Substantial software engineering jobs tend not to do "sprints"
| and no or limited "agile". You still want to always be learning.
| mlhpdx wrote:
| When I read the title I was curious what definition of
| "engineering" would be in play. I wouldn't call the process
| around programming and problem solving "engineering". I'd just
| call that "process", or "overhead", or (when feeling like
| speaking plainly, "inefficiency"). Who loves that? It's
| necessary, but loving it certainly isn't necessary (or even
| good?).
|
| I'd call the problem solving that balances technical, human,
| economic factors and produces great code "engineering". Knocking
| out code on a whim less so.
|
| My message is just be careful who you're speaking to when saying
| you don't want to engineer -- I'm my book you do.
| resource0x wrote:
| Switch to firmware dev-t. It's still tolerable.
| nktrnk wrote:
| I haven't spent much time thinking about the full extent of the
| metaphor I'm about to propose. But what you're saying sounds to
| me something like "do you hate being in a relationship but love
| making love?" Yes, many people would prefer one without the
| other. But that's not how it works in real life most of the time.
|
| And not only engineering vs programming or relationships vs love
| making. If you pay attention, many other aspects of life are like
| this too: -- do you like learning but hate school? -- do you like
| hiking but hate waking up early, driving, and sweating? -- do you
| like seeing new places but hate planning and getting there?
|
| Granted, sometimes some people manage to arrange their
| circumstances such that there's no dichotomy there. But most of
| the time, on average, this is what it is. There are two ways of
| dealing with it: accept it as a fact and learn to deal with it or
| try to change your circumstances with the understanding that
| there's a high chance it's going to be the same at another place.
| herbst wrote:
| I feel you. I am good at making software, I love doing it, but I
| dislike all the cooperate bullshit around it.
|
| What really gave me back the love to programming, building and
| even some corporate bullshit was doing my own things. Just solve
| a small problem, get really good at it and if you get bored just
| start working on the next thing.
|
| You choose your own tools, your working hours and how big you
| want to get. My suggestion is to stay small and safe time for new
| projects :)
| watters wrote:
| The corrupted forms of agile--which are so pervasive that they're
| now what most folks think agile is--have definitely make the
| experience of being a software engineer worse.
|
| Some of what you're describing can be found in for-hire firms
| that build out software to spec for other companies. The risk
| (for you) there is that, sometimes, you might have to learn or
| use new tools/tech.
| spacemadness wrote:
| So many folks have tried to guide the industry to better
| processes, but in the end the anxiety ridden micromanagers and
| control freaks win the battle at most companies. I think the
| problem is in the structure of businesses and its internal
| incentives to management and demands from stakeholders coupled
| with software being hard to understand and estimate. Every
| process will devolve into micromanagement and control.
| twblalock wrote:
| It's best to learn to deal with processes. Some companies do have
| really bad ones, and if that happens you should leave, but all
| companies will have some level of process, and every job will
| have some amount of work you don't like doing.
|
| Learning how to deal with this is a career skill. Remember that
| to your employer, you are not a coder, just as a firefighter is
| not a hose operator.
|
| To your employer, you are someone who delivers, maintains, and
| supports software. That requires a lot of non-coding work, and as
| you advance in your career the time demand for the non-coding
| parts of the job will increase.
|
| If you know how to deal with processes -- how to streamline them,
| avoid them, delegate them, and use them to your advantage -- you
| can build the kind of role you want. So, the good job for a
| person like you is a job where you understand how to work the
| processes in your organization.
| anotheracctfo wrote:
| This is 100% true for progressing to management. However the OP
| doesn't want management, which is fine, that's what principals
| are for. They should just find a good "servant leadership"
| manager who will get all the BS out of their way, and let them
| do "their job."
| twblalock wrote:
| Even ICs benefit from learning this stuff.
|
| There are really two paths: management or senior/staff IC. Up
| or out -- stagnate in a low-level or mid-level role, and you
| will get replaced with a younger engineer who will do the
| same work for less, or a contractor, or outsourcing. Everyone
| is expected to improve until they reach either senior/staff
| IC or management. You can't get there unless you learn how to
| deal with the non-coding parts of the job.
| jrochkind1 wrote:
| I think you just need a different workplace. A much smaller
| company? Academic/non-profit/scientific? The latter might mean a
| lot less money (that's where I work), but you might love it more.
| tonyaiken wrote:
| I like refactoring to make it look more elegant.
| FatActor wrote:
| What you are describing is:
|
| Hobby vs. career.
|
| You basically want all the fun creative parts without the process
| and review and maintenance required for a product that has
| responsibilities.
|
| It's like building a shed in your back yard vs. building a
| skyscraper in a city.
| GunjanKarun wrote:
| As a self-taught software developer, I understand your feelings.
| Many tutorials, workshops, and boot camps focus on the technical
| aspects of software development. Coding, fixing bugs, and
| handling incidents are thrilling and give a sense of
| accomplishment.
|
| However, when the applications I built became older, as more and
| more people started using them, and as the underlying tech stack
| continued to release new versions every year, I found myself
| spending more and more time patching up code to fix issues
| reported by users. I was patching the same code again and again
| or doing the exact change at ten different places and messing up
| in multiple ways. Since these applications were mission-critical
| for my clients, there was no way to avoid this.
|
| I realized that behind-the-scenes, "boring" concepts of planning,
| refactoring, discussing with team members, and architecting were
| essential for my future as a developer. These practices allow me
| to spend more time on the "fun" aspects of development and less
| on the "boring" stuff.
|
| It's similar to going to the gym. It may not seem important in
| the short term, but it's essential for a healthy long-term
| future.
| pdntspa wrote:
| I love most of the things around writing code but absolutely
| despise all the people that have popped up around it. Software
| engineering feels like a jobs program where we let nontechnical
| freeloaders figure out how to insert themselves into our process.
| I think that part of the reason that software sucks so much now
| is that the people designing it don't love software and
| technology the way we do, and it shows. I think we need to get
| nontechnical people OUT of our process and encourage more to be
| obsessive technical "lifers" and not corporate randos with
| business degrees trying to tell us how to make stuff.
| lifeplusplus wrote:
| Precisely my feeling on this topic. We don't need scrum
| Masters, product managers and even most managers who are not
| technical. Too many people trying to have a say in something
| they have no expertise in. Basically software engineers are
| treated like a coding monkey.
| stackbutterflow wrote:
| We need assistants not managers most of the time.
|
| Why are tech assistants not a thing?
| quickthrower2 wrote:
| That is what I find weird: when an Engineer spends the day
| fixing their PC or figuring out how to procure something.
| Assistants for that kind of stuff would be good. For small
| companies it might require a call out model rather than
| full time assistants.
| pillefitz wrote:
| Good luck handling software development, talking to
| customers, gathering requirements, aligning with other teams,
| doing marketing, writing budget requests - all by yourself.
| lifeplusplus wrote:
| pretty much what most PMs don't do exactly, they just take
| what managment says verbatium and just throw screenshots on
| top of another screenshot together without even bothering
| to properly account for most common states, research? user
| insights? etc.. it always goes like this: we made change x,
| our y metric increased. Waste of space.
| floydian10 wrote:
| Totally agree. I have some hope that the current high-profile
| layoffs makes (at least some) non-technical people to leave the
| industry. I have even started seeing more and more developers
| that have 0 interest in programming and are in it for the
| money, and it shows.
| redcat77777 wrote:
| i have interest in programming and i am in for the money, but
| the money is too small for the madness of the office
| 908B64B197 wrote:
| The great outsourcing panic of the late 90's and early 00's
| was pretty great at weeding out those who didn't care one bit
| about code.
|
| Anecdotally, but a new grad was telling me a number of his
| peers in college had the explicit goal of not coding two
| years out of a CS degree. Most of them were eying PM
| positions or "Tech Evangelist" roles.
| __dave__ wrote:
| I saw this exact same thing when studying CS in the early
| 2000s. A bunch of people said they only wanted to write
| code for a couple of years then get an MBA and become
| managers. Sounded crazy to me!
| Nevermark wrote:
| I remember in a third year OS class overhearing a huddle
| where the consensus was that computer science was a great
| major, but programming sucked.
|
| I was too traumatized to really process that for years
| ... lol.
|
| It is very helpful to my recovery to hear of other
| somewhat similar(?) experiences!
| lazybreather wrote:
| Code does not make money by itself. Business does. Code has to
| work for business. And if programmers can manage business,
| nothing like it. But someone has to. You can rarely have it
| both ways, code for fun and make money for the business too.
| And make no mistake, running a business is as difficult as
| building software if not more. If we assume that 'non-tech'
| people do not understand code, we can assume that 'tech' folks
| do not understand business too. Both of which are not true.
| Also, such a flaming rant on any other topic would be flagged
| out to oblivion. HN's predisposition with tech vs nontech is
| quite apparent.
| Tycho wrote:
| The problem is not so much the roles themselves, it's the
| number of non technical people who are staffing them. If
| someone has "paid their dues" as a developer, it's easy to
| trust their product vision, their roadmap, their design, their
| architecture, their delegation/organisation and decision
| making. But if they haven't, everyone feels uneasy and lacks
| confidence about the whole project. And the non-technical
| people themselves know this, and may even admit it - but either
| way it doesn't change the night-and-day contrast.
| adra wrote:
| There are plenty of non-technical people who have made my life
| happier. The more effective managers and business
| consultants/owners find a way of making my life easier by
| avoiding road blocks and taking on work that I didn't want to
| do anyways. The more frustrating ones would find arbitrary
| limits to my ability to produce or micro-manage.
|
| This isn't an everyone problem, this is an acute number of
| people who made production harder. By its nature, truly
| incompetent employees are eventually weeded out (assuming
| you're not in a dinosaur bureaucracy). If you're constantly
| finding that you're unable to work with the nontechnical side
| of your companies, you should start to question if you're part
| of this problem.
| 015a wrote:
| I think a critical reduction of your praise of good/effective
| non-technical people is: They made your life easier by
| triaging with all the other non-technical people.
|
| I wouldn't assert that this isn't valuable in most
| organizations; but it drives further into the OP's point that
| if non-technical people weren't involved in the process,
| things would simply Be Better; and large swaths of very real,
| numerous organizations do feel like work programs for people
| inventing work for themselves.
|
| Allow me to tell a story: I take on an epic of work. The
| final stage of this epic of work is to build out some UI
| stuff for a feature. Things get missed, we're approaching
| this final phase, boss says "oh crap, we need to coordinate
| with design to get some designs; I'll set up a meeting". The
| soonest they can get us in is two weeks. I spend three days
| twiddling my thumbs, then decide to Just Do It. We have
| component libraries; its like five UI components on an admin
| dashboard; just do it. I implement it; deploy to staging;
| then DM one of the designers "hey, I just released a new UI
| feature; if you have ten minutes today do you mind taking a
| look and giving feedback?" He had one piece of excellent
| feedback, I implemented it, and we shipped.
|
| Allow me to tell another story: Two days ago, someone from
| customer support DMs me and says "We got a security
| vulnerability report (links to ticket); are y'all the right
| team to look at this?" We were. I PR the fix, share with the
| team, done.
|
| Third story: Customer support DMs again. Hey we got a report
| from a customer about some odd behavior on this endpoint. Me:
| "Do you mind opening a ticket? That just helps us track it a
| bit better." "Sure man no problem (links ticket)". "Gravy my
| dude, I'll take a look at that tomorrow, sound good?"
| "Awesome!"
|
| There's nothing about any of these stories that would fly
| with many MBA Orgs' idea of "The Software Engineering
| Process". They certainly don't fly with _our_ process. It
| still happens. Why not? Once you start asking five-whys down
| the reasoning behind things like "it causes interruptions"
| or "engineers don't like talking to people" you eventually
| arrive at something proximate to: The MBAs invented a sandbox
| to justify their existence, they're here on a VC-fueled work
| program, and everyone has to play in their sandbox.
|
| Things are not better in that sandbox. Companies are less
| efficient. Employees have higher average misery. Revenues
| grow slower. But many are blind to it because the MBAs, if
| nothing else, are great at Talking Good, and we don't know
| anything else.
|
| (To be extremely clear: I'm adopting the terminology of
| previous comments, but think "technical" to mean "product-
| oriented", Product Managers and Designers count, and "MBAs"
| to mean "People & Process Oriented". Ex-Engineering
| Engineering Managers are gray area; but I think once you
| start viewing that role through the lens of buzzwords MBAs
| love like "Leaders" e.g. "To Lead Your People" e.g. "Inspire"
| "Mentor" etc; they can only be technical, and need to be more
| Product-oriented than People/Process-Oriented.)
| tcgv wrote:
| Great stories. For me the behavior you've described is what
| I see in a lot of experienced/senior devs. They're not just
| good at programming and building things, they're also good
| at interacting with other people to make things happen in a
| way that's efficient and brings value to the business.
| Existenceblinks wrote:
| I could imagine this could get worse. Incompetent CTO who likes
| a broken language and buy all the hype shit. This is how our
| job market is rotten.
| redcat77777 wrote:
| in marketing companies "projects" were lead by people after
| sociology, they were called account managers - why?? now i have
| a product owner who's above me and has no technical background,
| never used a cms, after 8 months i understood finally that the
| dashboard iam discussing is a poor man's google analytics page,
| we are making it because for the last 2 years people were
| taking stuff from the database and presented web stats by hand
| - each day i get to uncover more and more and more stuff like
| that . those nontechnical people think that they are doing
| rocket science stuff. like genuinely.
| jarek83 wrote:
| It sounds like you'd enjoy academic/research programming.
| Programming for business does not seem to suit you.
| hayley-patton wrote:
| University manages to sap my enjoyment of basically everything
| related anything, but I'm fine doing refactoring, rewriting and
| rearchitecting in my own time. Never really been employed, so not
| sure if sprints and agile are ever fun.
| mkoubaa wrote:
| Don't get promoted, an entry level dev does this pretty much all
| day
| primis wrote:
| I (Mostly) agree with you here:
|
| > Finding and fixing bugs is a lot of fun. Incidence response is
| a lot of fun. Hacking on new projects is a lot of fun. Writing
| unit tests is fun too.
|
| I'd agree on the first three, I'm not a huge fan of unit tests
| though. They seem like something a "good programmer" should do
| but to me it's in in the CYA lane, not programming.
|
| > Refactoring, rewriting, sprint, agile, rearchitecting things
| etc aren't that fun.
|
| I actually like refactoring code. To me it's like pruning a
| garden, moving stuff around to fit better. It also helps me on
| longer running projects to fix up crap that I wrote months/years
| ago. I'm always growing as a developer, and fixing foundations so
| they don't end up a cobbled mess is actually a pride point for
| me.
|
| Agile / Sprints / Pre-Future proofing / API contract writing?
| Pure overhead for me. My current job is a ridiculous amount of
| meetings. I get like 15-20 hours of meetings weekly in my
| position.
|
| This really boils down to being at a company that doesn't have
| technically knowledgeable management, and being on projects
| without a dedicated architect.
| t43562 wrote:
| Unit tests allow other team members (and yourself in 6 months)
| to make changes with much less fear.
|
| Sprints are supposed to be a few minutes where we spot early if
| someone is in trouble so we can fix it asap. The rest of the
| meetings should really be getting done by your product owner
| and maybe some kind of team lead. As you say it's usually a
| result of people not knowing things but sometimes that's the
| dev team too as in insufficiently well described requirements
| needing to be clarified.
| alakep wrote:
| Wow I am exactly the opposite. I do not like hacking. I like
| designing and optimizing and experimenting with new languages and
| strategies.
|
| I have mad respect for people like you, and always wished I was
| able to think in your way better. You should find a startup that
| has an engineering team that will complement (not mirror) your
| skills.
| kristopolous wrote:
| The money ruined everything. It spoiled San Francisco, the tech
| culture, polluted the industry with people passionate about money
| instead ... I'm not saying people shouldn't get paid, but if the
| richest tech person was #400 on the Forbes list and not known
| outside the industry as opposed to roughly half of them, I think
| we'd all live happier lives, including the Musks and Zuckerbergs
| of the world; they seem miserable. It's not in a healthy state.
| cratermoon wrote:
| I love taking existing code and making it better while adding
| functionality.
| fithisux wrote:
| Software engineering != Programming Software engineering != CS
| Programming != CS
| ranting-moth wrote:
| I dislike now that everything seems to be hacking around
| frameworks and dependencies, people don't want to (or can't)
| write code anymore. This is of course a rant, but you get the
| point. The following in a contrived example, just mentally
| replace it with whatever horror you've seen.
|
| There's an awful lot of very nice good quality libraries,
| frameworks and 3rd party code that I'm very grateful for. But
| there's also a lot of hacky stuff around that people blindly
| import as dependencies. Then it becomes someones else headache
| (mine!) to deal with it.
|
| I get a task to add a feature which isn't supported by the
| library that the new dev imported into the system. Turns out this
| library was someone's introduction to the C language and they
| decided to publish it.
|
| It pipes unhygienic user input straight to system calls and has
| boundary issues. It's mostly one function with a lot of
| conditional checks on arguments. There are three copies of the
| source file, one for each supported platform.
|
| I'm left with a insane task, PTSD and a deadline on Friday.
|
| Do I just pretend I didn't see that and hack in another feature?
| No.
|
| Do I tell the boss the problem? Yes. Will it delay the release?
| No, there's a demo on Monday and we have to release on Friday.
| Why Friday, we shouldn't release on Fridays!
| quacked wrote:
| An attitude recalibration may be helpful in this case. Software
| engineering is merely your "profession", and you perform it in
| exchange for other people providing you with clean water, cheap
| goods, security, etc. (Whether that's a fair trade is a different
| discussion).
|
| Unless you're an owner or a shareholder you're essentially a
| skilled laborer. Clock in, ply your trade, clock out. If they're
| jerking you around on hours get a better job or "quiet quit". Do
| things you like and feel fulfilled about in your free time, it's
| better to take joy and meaning in the society that you
| theoretically are working for the privilege of living in rather
| than looking for that satisfaction in your work.
|
| A quote I often think about from an article titled Smart Guy
| Productivity--"Son, I don't go to a place called fun, I go to a
| place called work."
| molsongolden wrote:
| Smart Guy Productivity Pitfalls -
| http://bookofhook.blogspot.com/2013/03/smart-guy-productivit...
| OhNoNotAgain_99 wrote:
| [dead]
| schwartzworld wrote:
| > Refactoring, rewriting, sprint, agile, rearchitecting things
| etc aren't that fun.
|
| Speak for yourself. Lots of those things are fun. Sprint and
| agile have more to do with the workplace, sure. But refactoring,
| rewriting and rearchitecting things can be really fun. The first
| implementation of anything is going to be burdened by complexity
| and wrong assumptions. It's only on the second time through that
| you have clarity. The joy of having the solution work pales in
| comparison to knowing that the underlying code is a thing of
| beauty. Like a jacket with a beautiful lining, paying attention
| to the details that nobody sees makes your product inherently
| better.
|
| > Finding and fixing bugs is a lot of fun.
|
| Refactoring is a part of this process. Squashing bugs and edge
| cases is fun like playing whack-a-mole, but it's also fun to see
| the bugs and edge cases as a chance to question your assumptions,
| is this really a one-off, or could I prevent all bugs of this
| kind in some way?
| Traubenfuchs wrote:
| Yes, I have never seen a working agile process. Only development
| where developers can either sleep the majority of the day or need
| to finish some death march for a feature management suddenly
| decided was needed yesterday to keep the company alive.
| Everything everyone is doing is theater, smoke and mirrors and
| clownery, kept alive by some implementation-champions and the
| super rare competent business people that burn themselves out.
|
| Software Engineering is disgusting.
| AJRF wrote:
| I feel like I am maybe "lazy" sometime because I avoid doing work
| because I know how painful it's going to be to get from working
| to "done". It just often doesn't seem worth the effort.
|
| When I work outside the constraints of my day job, programming is
| a fun creative pastime that makes the hours fly by. Last night I
| was up until 4am just hacking on something I was interested in. I
| honestly didn't notice the time go by (probably not healthy, but
| hey I was having a lot of fun so it's fine for me)
|
| The engineers I really respect often say similar things. There
| seems to be a gatekeeping class of software engineer who've been
| overfed on design patterns and enterprise software dogma that
| suck the fun out of it in big teams.
| m47h4r wrote:
| > Refactoring, rewriting, sprint, agile, rearchitecting things
| etc aren't that fun.
|
| Well you might not be aware but refactoring and rewriting are
| essential to any good codebase. No software is perfect because we
| aren't, and if you don't constantly keep fixing things
| (refactoring is fixing bad design), you will end up with a bunch
| of garbage to collect (pun!). Regarding methodologies and
| frameworks like agile and scrum (which includes sprints), you
| need some way to organize shit in an organization, real world
| problems cost the companies a lot of money, which in turn needs
| to be controlled as best as possible, agile & scrum are one of
| the ways we handle such things. I myself am not a fan of "trying
| to control the world" but it's necessary, I gotta suck it up and
| keep myself in harmony with others.
|
| > I'd rather get to value now by making something that just
| works(and is adequately tested) than engineer something thats
| future proof but takes longer to get out.
|
| This right here is why people argue over tests. So you believe
| you don't like rigorous testing, which is your opinion and it
| could/couldn't be valid based on the situation. If you are
| developing a program that controls airplanes, you need to make
| that as flawless as possible, otherwise you'll endanger lives.
| But yeah, if you're building a website for a small sweatshop, you
| can ignore tests and risk the occasional bad user experience that
| might happen due to your bugs.
|
| All this being said, to answer "What are some good jobs for a
| person like this?", I can assure you, you can find lots of jobs
| you will like if you understand why these things exist. I have
| worked on a project that management preferred to avoid tests and
| keep things flowing quickly, so your "getting shit done"
| mentality might be satisfied easily. Try figuring out exactly
| what you dislike and WHY you dislike them, only then you can
| figure out what kind of company (maybe smaller-sized ones) will
| best match your liking.
| scoofy wrote:
| I find myself spending most of my time writing tests for my
| website. It's grueling and I hate it, but it's basically akin to
| eating my vegetables, as I would be completely lost without them.
| lifeplusplus wrote:
| That's me... I loved coding, I did it in my spare time. Then I
| got a job it's been downhill since then. I thought maybe I was a
| junior. Then I thought I was at the wrong company. Then I told
| him maybe I was working in the role or programming stack?.
|
| But that's not it, I like writing code, I like refactoring code,
| I like debugging code but I don't like that it'd be held as a
| knife to my throat every day forever.
|
| At my job there has never been a slow day. At one of my past job
| our manager had to go for 2 weeks and that was the most
| productive we had ever been. We shipped more , built more ,
| collaborated more, and it all felt like a breeze.
|
| Right now I feel as engineers we have been subjugated to being a
| coding monkey. You are told what to do, when to do, how to do and
| how much you should have done by now. You are monitored, of made
| to dance, and forced to be glad that you even have the chance.
|
| I've spoken to people who have been in the industry for 10 15
| years and they say this was not how it used to be
| floydian10 wrote:
| 10+ years for me. It wasnt like this when I started
| lifeplusplus wrote:
| tts just isn't there yet
| black_13 wrote:
| [dead]
| neilv wrote:
| Maybe most of the contemporary practice of 'software engineering'
| is playing house.
|
| For example, "refactoring" used to mean a kind of later code
| changes to a working system, and tools to support it. Now I more
| often hear of it being used to mean what I'll call "fudge-
| factoring", to try to finish or redo a mess the same person made
| (possibly the previous week) so that they could pretend a sprint
| task was done, for metrics/peer-pressure reasons.
|
| Genuine software engineering is hard, but there are crafts to it,
| and you can find satisfaction and even aesthetic appeal in the
| crafts. And it can let you accomplish things that you either
| couldn't accomplish otherwise, or couldn't accomplish as easily.
|
| Maybe a comparison with programming is helpful. Programming is
| hard, but there's satisfying craft to it when you're doing it
| well, and when things come together.
|
| Now imagine the programming is being done badly -- most of your
| time is spent debugging, structural changes to the immediate code
| base are difficult, the tools are lousy, you have to spend other
| time figuring out some low-quality bureaucracy bloat other people
| made, people who don't know what they're doing have created a lot
| of wrong-headed theatre around pretending to address these
| programming-level problems, etc.
|
| That programming done badly is a lot like software engineering
| being done badly.
|
| Could a mythical software engineering done well be what you want?
| What if it wasn't piles of bureaucracy, but some magic
| professionalism that extended what you could accomplish with
| programming, removing some limits you found on what you could
| build before?
| toomanydoubts wrote:
| I love programming and I love software engineering. What I don't
| like is having to work for a living(in this case, doing SWE).
| speed_spread wrote:
| The truth is that "programming & solving problems" is only ever a
| fraction of a programmer's job even at the coolest company.
| You'll always end up having to first figure out other people's
| code and data, coordinate teamwork, support production
| environments, refine expectations (a.k.a. finding out what "the
| real problem" is), document critical procedures, improve tooling,
| and so much other _stuff_. And it's totally ok, because these
| things can be fun too! And because when you finally get to write
| code, if you're just a bit smart, you'll consider these other
| aspects and give them appropriate care in the way you code, so
| that maybe things are easier for everyone in the long run.
|
| What steals the fun out of the profession is the process, whether
| it's agile or lean or whatever. Having someone breathing down
| your neck for every bit of work you do, trying to categorize and
| measure every activity into a rigid grid to try and demonstrate a
| form of control over a process that we all know is essentially
| organic, if not chaotic. Smaller workplaces generally have much
| less decorum but given enough time all will grow their own
| process.
|
| At some point you figure out that the ultimate "problem" is
| always of human nature. The code you are paid to write and the
| problems you are paid to solve are _not_ yours. And that's
| precisely why you're getting paid.
| jvm___ wrote:
| How do you find and apply for jobs like this.
|
| Bug hunting mercenary would be my ideal job. Not sure how to find
| jobs that have that need.
| bratbag wrote:
| Quite the opposite. My happy place these days is working with
| higher level problems surrounding architecture, planning and the
| people behind the code.
|
| That's why I switched to management.
| matheusmoreira wrote:
| It's not that I hate it. I just don't care much about the
| problems that people actually pay programmers to solve. I'd
| rather think about the interesting stuff for which there doesn't
| seem to be much of a market.
| funnyfoobar wrote:
| Most of the software engineering jobs have the same process you
| described.
|
| But if you are into putting together new projects, possibly you
| might enjoy working at small consulting companies who are into
| building prototypes/MVPs.
|
| But if you join a company at post MVP, you might not get what you
| enjoy doing.
|
| Optionally, there will be some pure R and D jobs, which may not
| have the same processes that come with software engineering but
| you might have to read a lot of theory though.
| actinium226 wrote:
| I feel similarly. What I've found is that the way companies are
| structured the software engineers are usually in some sort of
| software department. I try to aim for roles outside of that
| department, like a software engineer embedded in some group
| that's more directly tied to the application.
|
| I've found that if I'm in the software department, the
| performance review and metrics and overall culture lean towards
| "how good of a software developer/engineer are you?" as opposed
| to "how good are you at solving the business's problem."
|
| That said, it's tough to make progress outside of the software
| org. Personally I'm doing a masters in math right now and
| thinking about a PhD in it as well, because I need skills outside
| of software in order to be able to make programming part of my
| job but not my career.
| birdyrooster wrote:
| Unit tests are not fun
| shahidkarimi wrote:
| 13 years ago I was so passionate about programing and software
| engineering. I used to stay in front of screen consucutively for
| 48 hours. But, now I realize that it was not for me. I tried to
| commit sucide three times. I was not good at soft skills. Though
| I solved many complex technical problems at work but did not
| excel in career. Its been 4 months I am jobless and I dont want
| to code again. I think software engineering and coding is the
| most painful job on the earth. I prefer death over doing it
| again. On the other hand I am running out of cash, I have two
| kids not sure what will happen in next 3 months.
| ryandvm wrote:
| I feel the same way. In my experience doing software development
| consulting, this is the difference between a startup (5-25
| people) versus a larger org (75+ people). The bigger orgs are all
| too happy to saddle you with endless meetings and agile busywork
| to the point that you're only actually coding about 5 hours a
| week.
|
| Startups on the other hand don't have time for all the bullshit
| because they're going to run out of money if they don't actually
| deliver. It's more stressful, more chaotic, but also more fun.
| agumonkey wrote:
| I think 'software engineering' is a misnomer. It's basically just
| like any large project, lots of fuzzy knowledge, swerving
| constraints, human group dynamics, quality check... The coding
| part is .. minimal.
| binarymax wrote:
| We can't go through life just eating cake all the time. We need
| to eat vegetables too.
| whateveracct wrote:
| I agree completely and have felt this way for years. And this is
| despite me getting a job at a "good job" (good benefits,
| generally respectful etc, cool language and tech).
|
| I went fully remote way before COVID. I've figured out how to cut
| my work with sawdust to get paid at work, and nowadays I'd say I
| spend more hours per workday on personal projects (programming
| and otherwise) than company work.
|
| So basically, I recommend making your job a low priority and
| focus on finding a remote company who will be happy with your
| output at that level of focus. Then you can get paid to do what
| you want in a way.
| whateveracct wrote:
| I'll add something to this here instead of editing:
|
| It's performance review season (feels like it always is now -
| twice a year and check-ins) and I do find myself not able to do
| those as well anymore. Because it's constantly about growth and
| desire for growth.
|
| I don't want to grow professionally anymore. It's not zero sum,
| but effort and focus spent on my career as a backend guy isn't
| going to benefit me compared to, say, playing guitar or
| drawing.
|
| So I have to bullshit my way through that with fake statements.
| In reality, I'll continue being as good as I currently am.
| Which is pretty good and people seem to be happy with my
| services.
|
| But the way companies use growth to effectively make you orient
| your mindset in their favor is definitely annoying. I see you
| plain, monster.
| RcouF1uZ4gsC wrote:
| A lot of this comes down to managers.
|
| I have been blessed to have really great managers who have been
| able to insulate the team from all the BS, while allowing us to
| unleash our creativity and talent in making great and useful
| software.
|
| Basically, they deal with all the pain so we don't have to, and
| as a result their teams have really delivered great value for the
| company.
| gghffguhvc wrote:
| I have a similar feeling but I've distilled it to something a bit
| different. I love programming where my human dependencies are
| motivated, smart and aligned. If any of those three are low or
| zero the fun can only last so long.
| thisisnotatest wrote:
| To quote the book by Google software engineers, "Software
| engineering is programming integrated over time".
|
| Programming is writing code at one snapshot in time.
|
| Software engineering is mapping that code backwards and forwards
| through time, making sure it works with what comes before and
| what comes after, in both technical and business aspects.
| birdyrooster wrote:
| Similar non-sequitur: Do you hate automotive engineering but love
| wrenching?
| hgs3 wrote:
| Processes are the norm at large corporations, but less-common to
| non-existent at startups. I'm guessing you're working for the
| former rather than the latter.
| scottrogers86 wrote:
| Try an early stage startup? Might be some super lean process in
| place -- maybe very light scrum, not even. Usually it's just "do
| this thing" -> ship it -> on to the next thing that sticks.
___________________________________________________________________
(page generated 2023-01-14 23:02 UTC)