[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 : 347 points
Date : 2023-01-13 11:57 UTC (11 hours ago)
| 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.
| 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
| 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"
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| adv0r wrote:
| the other way around
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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".
| 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.
| 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.
| 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.
| 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.
| brailsafe wrote:
| Yep. I'm sure there are comlabies out there that don't suck, but
| I haven't found them yet.
| 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.
| 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.
| 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
| 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.
| 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..
| 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.
| 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?
| 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.
| 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).
| 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.
| 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.
| barrenko wrote:
| Agile is like socialism at times.
| 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
| 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.
| 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!
| 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.
| 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."
| 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.
| 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.
| 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.
| 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?
| 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.
| 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:
| Using "people" might placate the sjw crowd but the
| writing is not as colorful. Most philosophers are men and
| most people stuck in unhappy marriages are men. Using the
| word men will stimulate those connections people have
| likely formed in their minds, creating a more relatable
| statement.
|
| If you're writing a PR statement, sure make something dry
| and non offensive, if you're writing for entertainment
| then lean into society's stereotypes.
|
| Don't bend to people's demands you change your writing,
| that just means your words have successfully produced a
| reaction!
| 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.
| 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.
| 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.
| [deleted]
| 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.
| peoplefromibiza wrote:
| [flagged]
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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
| 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.
| floydian10 wrote:
| Maybe hitting some hiring target?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| makestuff wrote:
| The downside is a significant comp reduction unless it is
| some sort of trading/hedge fund.
| 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]
| 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
| 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.
| 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.
| 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.
| 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.
| 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]
| 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.
| 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.
| capitanazo77 wrote:
| I prefer many small projects than big ones. Because complexity
| grows exponentially but payment and fun don't
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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!
| 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.)
| 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.
| 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.
| 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.
| 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
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
___________________________________________________________________
(page generated 2023-01-13 23:00 UTC)