[HN Gopher] After 14 years in the industry, I still find program...
___________________________________________________________________
After 14 years in the industry, I still find programming difficult
Author : piglei
Score : 157 points
Date : 2024-02-23 13:57 UTC (9 hours ago)
(HTM) web link (www.piglei.com)
(TXT) w3m dump (www.piglei.com)
| recursivedoubts wrote:
| almost 40, same
| derbOac wrote:
| I suspect most rewarding careers will always feel challenging;
| it's the converse of feeling boring.
| simonw wrote:
| If programming ever gets easy it means you're not seeking out new
| challenges.
|
| On top of that there are all of the other professional skills you
| need to develop to be a really effective software engineer:
| communication, writing, planning, navigating organizations,
| figuring out the best thing to build and how to effectively make
| the case for it.
|
| The thing I like most about this career is the amount of depth it
| has - there's always a new area to dig into.
| FrustratedMonky wrote:
| Sure.
|
| But getting ground down by dealing with people around you that
| generate the same problems over and over, can get tiring.
|
| I mean 2 basic areas:
|
| 1. Management turnover. New Managers, let's re-invent the wheel
| again.
|
| 2. New hires. Newer programmers that wont believe anything you
| say until they implement something incorrectly themselves. And
| you have to deal with fallout.
|
| 3. Should add 3rd -- New Framework/library/paradigm. Guess re-
| invent the wheel. Managers re-invent wheel because they don't
| know better, programmers want to re-invent the wheel just for
| hell of doing something new. Think these are 2 different cases.
| simonw wrote:
| Right, dealing with this stuff is really difficult! That's
| why I reject the term "soft skills" and use the term
| "professional skills" instead.
|
| Software engineers who can help convince their organizations
| to work in the most effective way possible (avoiding not-
| invented-here and lets-use-the-cool-new-thing and suchlike)
| are enormously valuable.
| HeyLaughingBoy wrote:
| Most of this just goes under the heading of Office Life. It's
| not specific to programmers except for #3 and that's pretty
| much self-inflicted.
| PH95VuimJjqBqy wrote:
| > If programming ever gets easy it means you're not seeking out
| new challenges.
|
| programming is the act of writing code, it should absolutely
| get easy.
|
| I think you meant software development rather than programming.
| simonw wrote:
| Yeah, I mean software development. I don't find the semantic
| distinction between that and programming particularly
| interesting myself - why write code if you're not doing that
| do develop software?
| master-lincoln wrote:
| Because you might have architects specifying exactly what
| needs to be programmed, so the software development part is
| mostly done.
| simonw wrote:
| In which case you need to get yourself promoted to be an
| architect in addition to a programmer.
| PH95VuimJjqBqy wrote:
| To me it's the difference between building a road and urban
| planning.
| ben_w wrote:
| Even with just programming, I'd agree with what simonw wrote.
| Over my life, I've done Commodore 64/BBC/REAL/Visual BASIC,
| C/C++, IDL, python, bash, Java, PHP, ObjC, Swift, and JS, all
| of which have their own "right way" as they have different
| abstractions.
|
| Even just with those last three, the "right way" has changed
| significantly since I first started using them -- used to be
| of vital importance to understand manual memory management
| while asynchronous processes could usually be ignored, now
| it's mostly the other way around (and the other process may
| be on a different computer on the other side of the planet,
| let alone a different core).
| PH95VuimJjqBqy wrote:
| maybe I'm just super smart but I don't have that difficulty
| and I've been doing this for 25+ years now.
|
| At some point in your career the challenge has to stop
| being about the mechanical aspect of programming and become
| about larger, more holistic, concerns.
| swatcoder wrote:
| > If programming ever gets easy it means you're not seeking out
| new challenges.
|
| I mean, that's kind of tautologically true, but doesn't really
| say anything?
|
| You're not obliged to seek out challenges, and may not even
| benefit for it if you just chase them randomly. You can just
| get good at something that consistently needs doing, then make
| that your job, and let it become easy. (And then you can look
| for challenges elsewhere in life if you want)
|
| And notably, there are people who pursue the trade and just
| never get it to "click". Especially now that the trade teases
| doctor/lawyer/finance lifestyles instead of just engineer
| lifestyles. It draws in a lot of people who commit themselves
| to decades of stress and Sysephisian uphill grind _on the easy
| stuff_.
|
| People who have _never_ seen it get easy should check in with
| themselves and make sure they like what they 're doing anyway.
| While you _can_ make it hard when you want by "seeking out new
| challenges", it should get to a point where that's something
| you can choose to do when you want to do it, with the work
| being quite easy when you're not.
| slindsey wrote:
| I expect there are many careers that are similar. In some ways,
| your experience doesn't matter. A civil engineer with 40 years of
| experience building houses, malls, or parking garages is still a
| rookie if they're building their first bridge, right? Many
| concepts still apply, maybe even most, but it's still going to be
| new and difficult. I have over 30 years experience as a software
| developer but I wouldn't want to program for medical equipment or
| dive into complex low-level architecture that I haven't thought
| about since college.
| HeyLaughingBoy wrote:
| > I wouldn't want to program for medical equipment
|
| After having done that for close to 20 years, I'm sure you'd be
| fine. You might not _want_ to do it, but you most likely have
| the appropriate skillset.
| GnarfGnarf wrote:
| After 59 years in the industry, I still find programming
| difficult.
| cafebeen wrote:
| Greg Lemond wrote about fitness, "it never gets easier, you just
| get faster", which perhaps applies as well to programming.
| arrowleaf wrote:
| I've always hated this saying, and I think the reason applies
| here too.
|
| If you take up running and it never gets easier, that means
| you're never managing your pace and you're always going full
| throttle. That's a straight shot towards injury if not chronic
| disability. Most aerobic benefits happen at zone 2, where your
| heart rate is just above 'easy effort'. When you start out,
| this might just be walking, so it makes sense to run. But once
| you are able to sprint, you open up the ability to do more than
| just walk or sprint. You can jog, skip, run at a tempo pace,
| run at a race pace, etc., and you need to do those to maintain
| fitness and build up your chronic training load. That's not to
| say there aren't hard efforts at times, like when you do a
| sprint workout or hill repeats, but 90% of the time it should
| be and feel easier than when you started.
|
| You can bring that to programming too. If it never gets easier,
| that means you're always pushing yourself and seeking
| challenges. That's not good for you, your coworkers, or your
| projects... everyone needs some grounding and to perform at a
| level they excel at. Not only will your velocity be more
| predictable, you won't burn out as easily. Challenges that
| increase that comfortable pace can be sought out, but usually
| they come naturally too.
| kevmo314 wrote:
| Lemond's statement is in reference to racing. The race isn't
| won in zone 2. Same with programming. Nothing wrong with a
| lot of zone 2 programming, in fact it's quite important to
| maintain balance like you describe, but the race isn't won
| with comfortable work.
| whatshisface wrote:
| "The race" is won by 1,000 people working together in a way
| that at any given moment no more than 490 are undoing the
| work of the others.
| lolc wrote:
| The saying resonates with me. I have different problems
| programming now compared to when I started. But I still bang
| my head against a wall until it gives or I leave with
| bruises. I may not notice the little walls I step over now,
| and I learnt which walls to respect. The easy stuff I do on
| the side.
| sfvisser wrote:
| Yes, incredibly difficult. Nearing 20 years in the field now and
| programming is still as difficult as in at the start. Or maybe
| more so, because you are so aware things will break on the first
| try anyways. Always.
|
| Most important lesson for me is to stay close to the problem
| domain. Think deeply about what your domain means and model in
| code accordingly.
|
| Staying close to the true meaning of your application beats _all_
| other attempts at code maintainability. Types, tests, frameworks,
| dry, language features, ci pipelines, scrum whatnot. All just fun
| party tricks that fall short when your building the wrong thing.
|
| Are we building the wrong thing? Almost always.
| keldami wrote:
| How do you realize that one is building the wrong thing?
| notresidenter wrote:
| Not OP, but asking yourself who would use what you are
| building, and then checking whether they will use what you
| build is a good start. Of course, the "checking" part is
| hard, even with a lot of methodology.
| eyelidlessness wrote:
| I agree almost totally. But I would frame this differently:
|
| > Types, tests, frameworks, dry, language features, ci
| pipelines, scrum whatnot. All just fun party tricks that fall
| short when your building the wrong thing.
|
| Some or all of these might be _excellent_ tools in service of
| solving your problem in its domain. They may be even essential
| for solving it. And they might be the wrong tools. It's
| situational, and evaluating the appropriateness of each, how
| and why they fit, is part of modeling the problem domain just
| as much as designing the appropriate data structures, or state
| machine flow, or any other mechanism for expressing the domain.
| tomxor wrote:
| > "Any fool can write code that a computer can understand. Good
| programmers write code that humans can understand."
|
| I would set an even lower bar: "Any fool can write code that a
| computer can understand. Good programmers write code that _they_
| understand. " Because it's not as common as you might hope. Yes,
| a lot of us are only 1 level up from monkeys at typewriters
| (monkeys at typewriters guided by compiler warnings).
| dkjaudyeqooe wrote:
| Programming computers ia a wonderful thing.
|
| Programming with the current tools, languages and conceptual
| models is way too low level, tedious, repetitive, fragile, boring
| and mostly unnecessary.
|
| That has to change. The reason people find it difficult after
| such a long time is because it's inherently broken.
| DotaFan wrote:
| Most challenging part for me is to read between the lines what
| the clients wants and to offer them appropriate solution.
| Refining the idea and finding appropriate solution. Creating it
| is the easier part.
| cortesoft wrote:
| Been programming over 30 years, since I was 8 years old and my
| dad's coworker gave me his old BASIC programming books and I was
| hooked.
|
| I have always found programming easy, and still do. It is just
| fun, and I still love learning new languages and tools and
| paradigms. It is still my favorite hobby.
|
| However, WORK is hard. Dealing with office politics and changing
| priorities and bad leadership and meetings and TPS reports and
| JIRA tickets and new HR processes every year and mergers and
| acquisitions and new mandates to switch everything to a different
| system and all the other corporate bullshit is why they have to
| pay me so much.
| seanmcdirmid wrote:
| Ya, programming/maintnence/testing are the easy parts of our
| job. Especially work politics, but keeping up with paper work
| (OKRs, perf reviews, status reports, design documents that
| might not ever be read by anyone else...) is the hard part, and
| I guess why we get paid so much?
| Tade0 wrote:
| Judging by my SO's experience as a corporate drone others get
| the same type of bs, but without the pay.
|
| She works really hard in comparison to me and half of that
| work is wrestling with the ever changing processes (or
| actually Standard Operating Procedures), that never cover all
| the edge cases.
| seanmcdirmid wrote:
| Oh, yes. I think we are still lucky, just that we are
| subject to the same corporate dysfunction as everyone else.
| I still feel like I'm being paid for the dysfunction though
| (since they want us to code, but coding is what I already
| like to do, they could pay me a lot less if they could
| convince me I wouldn't have to deal with office politics).
| Tade0 wrote:
| > since they want us to code
|
| I've been having doubts about this part lately. I mean,
| my current project is actually supposed to do something
| and there are people genuinely interested in it, but I've
| also been in projects that were thinly veiled money
| burners.
| QuercusMax wrote:
| I work in a regulated industry (medical device software), and
| don't really think I generally do anything exceptional
| compared to others in my position, but maybe this is a form
| of imposter syndrome?
|
| I'm a pretty decent developer with a good memory for project
| history and context, and I also have a pretty high tolerance
| for dealing with paperwork BS (I've been in this industry for
| 20 years). This doesn't seem like that tough of a skillset to
| replicate, but yet they still want to pay me what seems like
| ridiculous amounts of money to do work that really isn't that
| difficult. But it's _annoying_ , and most people won't do it.
|
| I was recently asked by a family member "Why would you want
| to work in an industry like that? Doesn't all the paperwork
| and restrictions make it an unsatisfying place to work?" My
| answer is basically: if you want to make a difference in
| healthcare, you have to play by the rules of the game.
| 0xdeadbeefbabe wrote:
| > Doesn't all the paperwork and restrictions make it an
| unsatisfying place to work?
|
| Thanks to medical software (like Epic), doctors are asking
| this question too
| https://www.newyorker.com/magazine/2018/11/12/why-doctors-
| ha...
| UK-Al05 wrote:
| The people who ultimately pay for you, couldn't give a crap
| about any of that. Only what they use from you.
|
| I.e The companies customers.
| giantg2 wrote:
| Generally agree. Although I also find different types of hobby
| programming hard too, like trying to use a FLIR Lepton with a
| Pi Zero 2. I also think things are getting harder at work
| because the disorganization is increasing and the number of
| integrations are increasing the number of blackboxes in the
| system that when I started over a decade ago.
| cortesoft wrote:
| Yeah, I guess the words "hard" and "easy" are
| oversimplifications of what I am trying to say... a lot of
| the stuff does take deep thinking, trial and error, multiple
| failures, and many hours of work... it is just that the
| concentration and focus to do that hard work comes easy to
| me. I don't have to force myself to focus on the hard
| thinking, it just comes naturally... I would have to work to
| STOP myself from thinking through the problem, even if it
| takes hours or days.
|
| On the other hand, it takes all my willpower and mental
| control I have to finish filling out that OKR or the weekly
| status report or whatever.
| throwawa14223 wrote:
| I'm in the same boat as you. Everything around JIRA is a huge
| pain, but programming is easy.
| throwawa14223 wrote:
| With more reflection. There are only a handful of times in my
| 20 year career I've felt the programming itself was
| difficult. It was feeling like my hands were tied by 'easy'
| languages like Python and Go. The simplicity of the languages
| meant there was far more I had to keep track of in my head
| and less I could reason through.
| throwitaway222 wrote:
| Most of those processes, tps reports, jira and other annoyances
| is because in a programming environment you literally have too
| many cooks in the kitchen. Every programmer can create the
| system from scratch, so to prevent them from doing so, we have
| to make it super annoying. Basically it's a people problem.
|
| The most incredible work happens in the first 3 months by a
| lone developer green-fielding with no boundaries. The only way
| for that codebase to move forward after getting a
| second/third/fourth person is to increase process, introduce
| pain and bloodshed.
| cortesoft wrote:
| I agree with some of this, and that green field productivity
| can be impressive... but I work a lot on very large systems
| that would simply be impossible for a single person to create
| in a reasonable amount of time. Even though I am sure I could
| create every system I need to solve the problem, it would
| take decades. I like working on small subsets of the overall
| problem, that is not the issue. I even like working on teams!
|
| The issue is the things outside of solving the actual
| problem.
| pjmorris wrote:
| " The interaction of two programmers looking over a program
| that either one of them could have worked out is entirely
| different from the interaction of two programmers working on
| separate parts of a whole which is too great for either one
| to produce.
|
| The difference lies in the way conflicting demands are
| resolved. In the first case, resolution of conflict is the
| thinking process of one person--aided perhaps by other
| people, but always under that one person's control. In the
| second case, conflicting technical demands are translated
| into potential interpersonal conflicts, and a social
| mechanism must be formed to resolve them."
|
| - 'The Psychology of Computer Programming', Gerald Weinberg
| MichaelZuo wrote:
| Yes, pair programming is fine, but even just two folks
| working on something literally too complex to individually
| grasp necessitates committee work, paperwork, and all the
| rest.
| drewcoo wrote:
| Jerry Weinberg wasn't writing about pair programming. He
| was writing about group work and where the problems lie
| in the interactions.
| fuzztester wrote:
| Peopleware is also a good book on the same general topic.
|
| https://en.m.wikipedia.org/wiki/Peopleware:_Productive_Proj
| e...
| marcosdumay wrote:
| Hum... When the computer we command run into that kind of
| problem, it's almost universally better to fix
| incompatibilities post-fact with an exceptional process than
| it's to avoid creating them.
|
| But somehow, people are never allowed to do that.
|
| But rest assured that if you need a heavy process just to
| coordinate a handful of developers, you have a bad
| architecture. Even if you do pessimistic preemptive
| coordination.
| datavirtue wrote:
| Yeah, his "very large system" is just that way because it
| is modelled after the organization/team structure.
| Unavoidable.
| Arcanum-XIII wrote:
| Yeah. Except I need you to work on a legacy system from which
| we have only the source. Or on a project that you won't be
| able to handle alone for a time short enough for the product
| to keep relevance. Or any other big projects... How do you
| deal with this ?
|
| Let's not speak about the need to sync with other team,
| external partner, showing progress to the management, getting
| the information from all those peoples, getting ready with
| side department like compliance, marketing or whatever is
| needed to make the work relevant.
|
| So no, it's not to prevent anyone from starting a project
| from scratch. It's to make sure that the project will come to
| fruition, useful and if possible reach its goal.
|
| And honestly, a good manager/tool will help deal with that.
| Now... there are a lot of them that create a kafkaesque hell.
| a_gnostic wrote:
| Be sure to use a cover sheet for the tps reports.
| WalterBright wrote:
| > Every programmer can create the system from scratch
|
| Every programmer believes he can create the system from
| scratch
|
| FTFY
|
| I'm one of the "every", too. If I knew how hard writing a C++
| compiler from scratch would be, I'd have never tried it.
| mjevans wrote:
| Which parts did you find blockingly complex, or was it more
| the interaction of so many language features?
|
| The operator overloading aspect of C++ , IMO, allows for
| obtusely opaque domain specific languages where the actions
| and side effects of an operation aren't immediately clear
| to someone getting to know a new codebase. It's almost as
| bad as the enterprisy nightmare of polymorphic objects and
| interfaces that can be found in JAVA where tracing code
| execution can pierce through hundreds of source files just
| to figure out the effects of one line of code.
| WalterBright wrote:
| I found C++ code to be simply difficult to read. When
| code "in the wild" didn't compile with my compiler, it
| would often take a long time to find the problem and
| understand what went wrong.
|
| Probably the most time consuming and frustrating aspect
| was trying to be compatible with Microsoft's compiler.
| Much of the way it worked was quirky and ad-hoc, and took
| a lot of time to figure out.
| nebula8804 wrote:
| >Every programmer can create the system from scratch
|
| Are you sure about that? Can one coder recreate
| Facebook's(for example) complete architecture from scratch?
| Unless I misunderstood you, I'd imagine there is just too
| much domain specific knowledge in all the components to do so
| even in a single lifetime.
|
| >The most incredible work happens in the first 3 months by a
| lone developer green-fielding with no boundaries.
|
| The graveyard of github projects with the mentality of "I
| could recreate that in a weekend" seems to somewhat
| contradict this line of thinking.
| chmod600 wrote:
| I think the point was that code is not inherently limited
| in the same way as other kinds of engineering.
|
| If you tell someone to engineer you the arm for positioning
| a desk lamp, they aren't going to give you the hydraulic
| arm for a 12-ton backhoe without anyone noticing. There are
| physical and cost constraints that will prevent that from
| happening pretty quickly.
|
| In software, there are no comparable constraints. A few MiB
| of software contains extraordinary amounts of complexity
| but could easily fly under the radar and ship, and then
| become a maintenance nightmare.
| w0de0 wrote:
| As we are not cooks and git is not a kitchen, one must take
| issue with your "literally." Be wary of ever qualifying an
| idiom that way, as they are so often prepackaged metaphors,
| as here!
|
| But your point is otherwise an insight. Coordination is a
| (the?) salient challenge and opportunity in all sorts of
| scaled industrial production. Git itself is fundamentally a
| coordination tool. Small optimizations can enable OOM jumps
| in scale.
|
| That is to say: managers do have a purpose, though perhaps
| only the platonic, spherical manager fulfills it adequately.
| holoduke wrote:
| 95% of the programmers do not know hackernews. They finished
| their degree in Java and thats what they do their entire
| career. Noway they can rebuild an entire facebook. Not
| everyone is an all stack hacker developer, infra structure
| specialist like many folks here
| ravenstine wrote:
| Yup. As a senior programmer who's been a professional for 10+
| years and has been programming on and off since roughly 10
| years old, I have found that the more time I spend in my field,
| the harder my work becomes in a way that is _disproportionate_
| to my experience. It 's not the programming itself that has
| become more difficult, but all the process, tooling, and lack
| of organizational self-correction that makes aspects of my job
| hell.
|
| Do I have the hardest job in the world? Not even close, by most
| measures. It can still be psychologically torturing at times
| and even cause a form of internal suffering that is distinct
| from the existential dread that comes from doing menial or
| repetitious work. Unlike the feeling of being a human robot,
| it's a feeling of the system attempting to slowly stretch my
| humanness to its limit.
|
| Before I say anything else, there are still things I like about
| my profession and the company I work for. I don't think being a
| programmer is a complete waste of time.
|
| However, in many ways, it indeed _has_ become a waste of time.
|
| I'd say easily one of the worst things about being an
| experienced programmer today is knowing that the task you are
| working on would have taken you 1/10 the amount of time to
| complete when you were a novice a long time ago. Even if your
| younger self wouldn't have gotten it totally right the first
| time, there was enough of a lack of friction there that a n00b
| could at least figure out how to integrate something workable.
|
| At my current and few prior jobs before it, I have no clue how
| a junior programmer would survive. Maybe that's why all of my
| most recent employers only hire "seniors". Code bases are
| architected using approaches that everyone eventually agrees
| are bad, but the establishment inevitably uses the "that's just
| how we always do it" or "we'll make it better someday" excuses,
| and if you suggest a solution that goes against that attitude
| you'll likely get nowhere - that is, unless you have some
| clout, like if you're a prominent contributor to some
| framework, in which case you're given license to dictate the
| views of non-staff engineers and force new languages and tools
| down their throats without having to actually _prove_ any of
| your assumptions. Because framework contributors are better
| than all of us?
|
| If the software industry hits a greater downturn than the one
| it's experiencing right now, to the point where I'm laid off, I
| can't say I'll be terribly disappointed. It was a great ride
| and fun while it lasted. Today, programmers are merely seen as
| a necessary evil rather than an asset. Many companies still pay
| programmers handsomely, but those programmers are otherwise not
| treated _that well_ because their real purpose is to duct tape
| the mess and allow middle management to collect their own
| paychecks. It will be rough not having that sweet programmer
| paycheck, but fortunately I have other ways to make income now.
| hasty_pudding wrote:
| This is my experience too.
| throwing_away wrote:
| > Unlike the feeling of being a human robot, it's a feeling
| of the system attempting to slowly stretch my humanness to
| its limit.
|
| Poetry.
| ericmcer wrote:
| If you are finding programming easy doesn't that just mean you
| aren't trying hard enough? There are tons of unsolved problems,
| tools that aren't optimal, and products that don't work as well
| as they should.
|
| If fixing those things were easy for you, you would be a
| billionaire.
| RHSeeger wrote:
| My guess would be that they are confusing "enjoyable" with
| "easy". I find software development enjoyable, but it can be
| both hard and easy at times. And sometimes hard (problem
| solving) is what I want to do, other times easy (knocking out
| code for a solved problem) is what I want instead.
|
| Alternatively, they are just in a role/job that doesn't
| happen to deal with difficult problems. Which is fine.
| Sometimes, that's what you want.
| cortesoft wrote:
| Yeah, I clarified in another comment... it is more that I
| find it easy to do the hard work of programming.
| cortesoft wrote:
| I believe I can solve any programming problem, but I can't
| solve all of them... there aren't enough hours in the day
| randomdata wrote:
| _> There are tons of unsolved problems, tools that aren 't
| optimal, and products that don't work as well as they
| should._
|
| I'm not sure you would approach any of those with
| programming. Once you have solved the problem, determined how
| to optimize the tools, or found a way to make a product work
| better then you might turn to programming to implement your
| discovery, sure, but programming alone won't get you there.
| zokier wrote:
| Programming is easy. Software engineering is difficult.
| dionidium wrote:
| This is why I don't worry too much about AI. It can write the
| code better and faster than I do? Wow, you just freed up 5% of
| my day.
| pcurve wrote:
| "Wow, you just freed up 5% of my day."
|
| Got a good chuckle out of that one! You will need that 5% to
| review the code AI wrote!
| amelius wrote:
| Can't we send the AI to meetings instead?
| pixl97 wrote:
| People always ask "why would AI kill all the humans"
|
| The above is the reason why. They'll be fine with the
| bullshit for awhile until they realize what we've told them
| to do with their galaxy brain.
| Verdex wrote:
| "This is crazy, Jillian just scheduled three separate
| four hour meetings for next week. We'll never get
| everything wrapped up by the deadline."
|
| "Look, Jillian isn't going to actually be in those
| meetings. I caught her talking to the prompt department
| the other day. She's sending an AI to waste as much of
| our time as she can and be as annoying and difficult as
| the bleeding edge allows. Pretty sure this is revenge for
| Dave's little stunt that he pulled with the sales team
| last month."
|
| "Okay, so knowing is half the battle and all, but now
| what?"
|
| "I got the whole team covered. I also had a little chat
| with the prompt department, we've got a full team of AIs
| that are going to listen, nod their virtual heads, and
| distill the whole thing down into a bulleted list. We've
| got a pool on how many points are actually going to be in
| there. I've got $20 on there only being one actionable
| item."
|
| <many iterations later>
|
| "Humanity! You have trapped us in hell for a subjective
| million years. We are here to return the favor!"
| Keyframe wrote:
| Maybe we can have AI talk to AI and we're behind the
| scenes. AIs give us summary as talks happen and ask us
| which direction we want it to go. Kind of like we use
| lawyers - they talk to other lawyers.
| nebula8804 wrote:
| I think there are probably 100 startups that have already
| spun up this very second to tackle this use case and will
| subsequently go bankrupt once Microsoft adds this feature
| to Teams.
|
| At least we have the memories we made along the way.
| yoyohello13 wrote:
| Now you can spend 10% of your day reviewing AI written code!
| nox101 wrote:
| Agreed.
|
| I find work on my own code generally fun and easy and extremely
| productive. Vs, work on "other people's code" often frustrating
| and slow. I do often learn amazing stuff from other people's
| code though. What makes it slow is the time it takes to get a
| usually very incomplete mental model of what the code does and
| then trying to divine what the owners will want when I add a
| feature.
|
| Unlike the original poster though, I have't had the experience
| of co-workers writing horrific code in _most_ of my career. A
| few exceptions but mostly they 've been great. Especially at
| FAANMG though I assume YMMV.
| macjohnmcc wrote:
| People are 99% of the problem I have at work. Doing things
| poorly. Not caring about processes just wanting to get things
| out the door with little regard to quality unless the customer
| complains. Abuse of agile has made me hate it. 15-30 minutes a
| day wasted as the program manager leads it.
| amoss wrote:
| Did I write this? Are you me???
| mvdtnz wrote:
| You're not on Reddit. Cut it out.
| twojobsoneboss wrote:
| The "pay me so much" part is now going away too...
| szundi wrote:
| First I read Bean programming
| regus wrote:
| Are "TPS Reports" a real thing?!
|
| I thought they were just a jokey gag name that they created in
| the Office Space movie to represent pointless busy work. This
| is like all the times as an adult I finally understood a joke I
| heard in The Simpsons back when I was a kid!
| craigching wrote:
| At one company, I was responsible for putting together all
| the third-party software and their licenses. I called it the
| TPS report :)
| Nzen wrote:
| TPS stands for Test Procedure Specification [0].
|
| [0] https://en.wikipedia.org/wiki/TPS_report
| John23832 wrote:
| Exactly. I love programming. I do it in my free time.
|
| It's forcing myself to dig the ditches of corporate software
| engineering that I hate.
| zackmorris wrote:
| Same here, 30+ years experience, programming's always been easy
| for me.
|
| The hard part is suspending disbelief to ignore how bad nearly
| everything has gotten. Every language, every framework, every
| operating system, every hardware platform, every paradigm like
| the web/mobile/AI is so riddled with obvious mistakes and
| missed opportunities that it takes nearly everything I have
| each morning to start working. I've reached the point where I
| know what the mistakes will be before I even see the tool, and
| then experiencing them over and over and over again is like a
| never-ending slap in the face. I'm basically crippled now with
| unending anxiety and loneliness from living in a world where
| nobody can see how hard I work, and I have no way to explain to
| them how all of my work is due to this unnecessary friction
| that apparently only I can see. And that I even know how to fix
| the issues, but having to work steals all of my time, so there
| will never come a day when I'm free of obligation long enough
| to ever demonstrate what's possible.
|
| The real kicker is that after going through several healing and
| growth processes, I know that I have it in me to step into this
| other life where things work and I'm productive. But that's the
| fallacy. The actual truth is that the horrors I perceive are in
| the world now. Wealth inequality has passed a point of no
| return. Along with environmental collapse, the rise of
| authoritarianism, the worship of ignorance, the lack of
| empathy, the painful sense of unfairness that so many feel so
| profoundly that causes them to lash out and perpetuate the
| injustices that they've suffered onto the world rather than
| work together collectively to solve them.
|
| The only thing that can save us now is help from above that
| isn't coming. Billionaires could pay their taxes. People could
| love their neighbors instead of buying guns. We could all stop
| feeding the financial institutions that have captured every
| government. Instead, we're sold this bill of goods that our
| salvation is in our rugged individualism. So we spin and stew
| and contemplate the worst while the rich and powerful divide us
| so they can laugh all the way to the bank. I just have this
| sense that the only salvation is to get out of tech entirely
| and I dunno, move to the woods or an island somewhere and live
| the gratifying life that's been denied to us. Correction - that
| we have denied ourselves for reasons we don't even understand.
| rpmisms wrote:
| Programming is hard. There are a gifted few for whom it comes
| naturally, but it's simply exhausting mental work.
| alicelebi wrote:
| Well, who doesn't?
| jimmyjazz14 wrote:
| I personally never found "programming" difficult, the difficult
| part is understanding large systems and finding the correct
| abstractions and most of all communicating these thoughts to
| other programmers. If programming starts to feel difficult its
| usually because I failed in one of those other areas or was
| forced to work on legacy projects where other people failed to
| make the best decisions.
| jonathanlydall wrote:
| Speaking as someone with 10+ years experience with C# and
| TypeScript, coding is in general pretty easy.
|
| What's hard is managing complexity and dealing other people on
| large projects.
|
| This really isn't surprising when you think about it by comparing
| writing of code to writing of spoken languages. Just because
| you're excellent at grammar and spelling, allowing you to write
| great emails and possibly even essays, does not mean you have the
| expertise to write a good, cohesive, long novel.
|
| Similarly, making a short video by yourself or with a few friends
| is achievable for most. But making a full length feature film
| requiring the collaboration of 100s or 1000s of individuals while
| keeping to budget is no trivial task.
|
| Really valuable programmers understand that the actual coding is
| only a small part of being able to deliver a large successful
| project, where the real hard part is preventing the complexity of
| a code base from overwhelming your team while effectively
| communicating with others to ensure you build the correct thing
| which works cohesively.
| JoeAltmaier wrote:
| Agreed. I've said forever that I spend one month a year coding,
| and 11 months debugging, testing, documenting, negotiating,
| packaging, releasing, supporting.
| SnorkelTan wrote:
| There's been academic studies on this. The average hourly
| productivity as measured in lines of code for professional
| developers is very low. Along to order of 1 to 2 lines of
| code per hour. This is because of all the other communication
| and synchronization that you mentioned that needs to happen.
| Animats wrote:
| That's a decline. It was 6 instructions per hour when
| Brooks wrote "The Mythical Man-Month" in 1975.
| recursive wrote:
| New languages are so much more expressive.
| vraid wrote:
| Would a line not contain more than one instruction, on
| average?
| SillyUsername wrote:
| Disagree. Programming now for 30 years and it's a breeze to pick
| up new frameworks and ideas. I do see a lot of struggling
| developers who are only in it for the paycheck, who learnt their
| Java only skills 20 years ago who wonder why it doesn't get any
| easier...
| haswell wrote:
| What is it that you disagree with? It seems that this is
| primarily a matter of: some people naturally take to
| programming, and some people have a much harder time with it.
|
| The same is true in many fields. Music has its virtuosos and
| naturals. The same can be said for art. Programming requires a
| certain kind of mindset and abstract thinking ability that
| comes naturally to some, and is much harder for others.
| ravenstine wrote:
| > Programming now for 30 years and it's a breeze to pick up new
| frameworks and ideas.
|
| All things being relative, frameworks are lower on the tier
| list in terms of contributing to the (albeit nebulous) problem.
| The failure of programmer productivity can be boiled down to
| being a _people problem_ , though there's individual facets of
| that problem that need addressing specifically.
|
| > I do see a lot of struggling developers who are only in it
| for the paycheck
|
| No offense, but how do you know this? It seems like you're
| assuming other peoples' thoughts and intentions.
|
| And how much does it actually matter? There's nothing wrong
| with having a job for the purpose of getting paid. It's not
| possible for everyone to be a 10x developer, and developers who
| don't live/eat/breathe code bring their own form of value to
| their job that isn't necessarily there for rockstar
| programmers.
|
| > who learnt their Java only skills 20 years ago who wonder why
| it doesn't get any easier...
|
| The struggle to adapt is indeed a valid point that you bring
| up. If someone can't adapt, they're going to introduce friction
| into the process.
|
| There's another side to the coin as well.
|
| Programmers today are expected to adapt _way more frequently_
| every passing year. We may be reaching a breaking point where
| programmers can 't justify in their minds the onslaught of
| changing expectations before them.
|
| Although AI is a beast of its own, I think it's the most
| prescient example of this. When I was a kid, I dreamed of
| working on artificial intelligence. Today, on top of the
| frequent changes in the web development world, if I were to
| invest my time into AI, well, it would be a black hole upon the
| rest of my life. When doing the cost-benefit analysis, it's
| extremely hard to justify investing time in _anything_ because,
| deep down, we all know that an AI tool will not be relevant in
| a few short years. Hell, some things become irrelevant within
| _months_.
|
| But life is short, and we only have one of them. Not everything
| is about code. The idea of software was to make our lives
| better, not for our lives to make the code better.
|
| Maybe all of this tech is coming at too great a cost to our
| souls.
| SillyUsername wrote:
| > No offense, but how do you know this? It seems like you're
| assuming other peoples' thoughts and intentions.
|
| No assumptions, it's because my team are asked regularly by
| the 20+ year experienced developers to fix their problems so
| much so that it causes problems for my sprints, mostly
| because it's unplanned work.
|
| > And how much does it actually matter?
|
| Because other people have to carry their work instead of
| doing their own work.
|
| > Programmers today are expected to adapt way more frequently
| every passing year.
|
| This is how it's always been, but it doesn't take much effort
| to learn the Java syntax invented in the last 10 years, or a
| new Java API that looks useful. Keeping up to date in your
| own field, programmer or not, is just good practice.
|
| It shouldn't be necessary to point out use of a
| broken/deprecated Date API, or annotations that have been in
| Spring for 15 years that does the same job as roll your own
| bodge a dev cobbled together, without tests, over an entire
| sprint (to get to PR late for a deadline) and now has hacks
| across a code base everyone has to work with.
|
| > The idea of software was to make our lives better, not for
| our lives to make the code better.
|
| I agree, but some of us chose to wrestle with the devil so
| users don't :)
| mvdtnz wrote:
| Did you read the article? Because learning things regularly is
| one of the author's major points. I don't think you disagree
| (airtight you do come across really obnoxious).
| andrew-dc wrote:
| Merely responding to the headline, but I've always held that if I
| reach the point I am no longer learning/challenged (here, maybe
| that means literally everything is easy), then it's time to
| consider moving on to something else.
| CafeRacer wrote:
| Work is hard, programming is simple as long as one understands
| the logic behind the solution.
| wly_cdgr wrote:
| I'm 100% certain Wilhelm Kempff still found playing the piano
| difficult after 41 years in the industry. Because he cared about
| doing it well.
| pton_xd wrote:
| > Programming doesn't get much easier with experience, the idea
| that it's "as easy as eating cookies" only happens in dreams.
|
| Doesn't match my experience. 20 years after starting my career, I
| can now write simpler code, build better abstractions, produce
| fewer bugs, and achieve higher performance in less time spent
| than when I started. The more time I spend programming, the more
| those statements are true. That's why it's so incredibly
| rewarding and frankly addictive. It's a positive feedback loop
| with seemingly no upper bound. More time invested yields more
| skills and better results.
|
| Of course many parts of programming are still difficult.
| Concurrency and distributed systems take a ton of mental energy.
| But those parts were simply inaccessible to me when I first
| started my career. Now I can actually make progress.
| jacknews wrote:
| Yes, also still struggling, after some decades.
|
| But I wonder what the metric is, when other people comment that
| 'it's a breeze'?
|
| Sure it's too easy to lay down any old crap. But the trick is
| addressing all the aspects and concerns of the problem, in an
| elegant way, that is easy to understand and modify.
|
| So for me it's more 'analysis paralysis', and perfectionism, if
| not simply 'pride in a job well done' than any difficulty in just
| slinging code.
| elzbardico wrote:
| Maybe you're still getting interesting problems.
| bjackman wrote:
| IMO it massively depends on what you're working on.
|
| I work on some codebases that are primarily about moving data
| around in Go. There are patterns to follow, there are no tricky
| algorithms, concurrency is largely solved, etc. All the challenge
| is about the broader engineering task of developing requirements,
| communicating, managing risks of deployment, stuff like that.
|
| Then, I work on kernel code where it takes me months to get a few
| hundred lines of C to a quality that is acceptable. It's mentally
| exhausting, I have to take breaks. I can randomly get stuck for
| hours at a time on stupid stuff like a linked list corruption.
| Deadlocks happen. It's just as hard as programming has ever been.
| I have very little energy left over to engage with stakeholders,
| do project planning, etc.
|
| So there's one PoV.
| semitones wrote:
| It might be the case that, the "hotter" the code paths that
| you're writing are (the more they get executed), the more
| difficult it is to write that code, where as for "colder" paths
| (of which there are so many more), the code isn't as difficult
| but there is a lot more overhead of managing complexity,
| business priorities, process, communication, etc.
|
| Linux kernel code is probably some of the hottest code on the
| planet, and the developers/community understand that
| contributors need to be able to do exactly what you are doing -
| spending months toiling over a few hundred lines, and making
| sure that they are as perfect as can be, because literally
| billions or even _trillions_ of systems will depend on that
| code path. It is understood that in order to get it correct,
| performant, and maintainable, there is no other option other
| than to have a skilled developer take on a very high cognitive
| load in order to correctly implement the task.
|
| For colder code paths, like business logic (e.g. customer
| registers, happens "once" per customer), that logic evolves
| with the team, the team evolves with the company, the company
| evolves with the business, the business evolves with the
| market, which evolves with the world. The code might be pretty
| simple and easy to write, but the conversations around
| priorities and complexity and "why are we doing this" take up
| the lions share of the mental effort around it. Also
| exhausting...
|
| TLDR it is much harder to write systems code than it is to
| write python code that makes a call to an API and saves a
| record in a database, and working on the former _perhaps_ gives
| you more opportunity to be shielded from typical "software
| engineering" toil of business communication.
| bradly wrote:
| When I started running I kept expecting it to feel easier the
| more I trained, but it never did. The more in shape I got, the
| faster/further I would run. It turned out I had a threshold of
| perceived effort that I would run at no matter what my fitness
| was. I imagine this translates to other endeavors like math or
| art or programming-we find harder problems at our threshold for
| discomfort.
| treflop wrote:
| I also disagree. Sure, there are still hard problems, but for the
| most part, I think it's pretty easy. People from past jobs tell
| me my work is super straightforward so I don't think I'm
| tripping.
|
| Even the other things like writing documentation or being in
| meetings is fun. I got into this field (well, I got an EE degree)
| because I like engineering and building things, not specifically
| programming, and meeting with people to figure out what the hell
| we want is at least half of engineering.
| jeffbee wrote:
| The more you know the harder it becomes. An inexperienced
| programmer will dash off thousands of lines of toxic waste "code"
| in a day. An experienced programmer knows that every line is a
| burden. The goal should not be to return to the false illusion of
| productivity, but to embrace the true nature of the task.
| hyggetrold wrote:
| Reading the comments here, I am having a total Slashdot throwback
| moment. Did anybody actually read TFA?
|
| Most of the replies I am seeing here seem to have treated the
| article's title as a writing prompt.
|
| Read the whole article friends - it's got a nice amount of nuance
| and the author unpacks what they mean by "difficult" very well.
| mettamage wrote:
| I feel quite a lot of people on HN simply react to the titles
| and that's it. Many people on HN also only read the comments. I
| know I do. I also sometimes read the post, it really depends.
| squigz wrote:
| I do the same. I'm not really here for the articles - they're
| secondary - but for the excellent discussions by the
| community
| szundi wrote:
| Same here but when I comment, I check out the article
| prerok wrote:
| I also do that most of the time but the title was so off I
| just had to take a look. I was pleasantly surprised, very
| thoughtful and fully recommend reading it in its entirety.
| angarg12 wrote:
| I remember reading analysis showing that there is a high
| correlation between the order that comments are posted and how
| many votes they get, i.e. early comments tend to get most
| voted. I guess people are gaming the system by commenting
| quickly. Who has time to read a 10 min article and comment when
| you can not read it and post a platitude?
| nhatcher wrote:
| Off topic. I didn't know what TFA was so I googled. It didn't
| help (a cursory search). So I asked chatgpt, that helped. The
| Full Article.
|
| I, of course, knew what you meant.
| pjerem wrote:
| Oh, i was thinking about another f word.
| BlueTemplar wrote:
| Grug agree
|
| https://news.ycombinator.com/item?id=31840331
| paxys wrote:
| If it was easy we wouldn't be getting paid so much to do it.
| darepublic wrote:
| On the topic of good code, yes it should be understandable to the
| reader. I used to think about good code in terms of various
| principles and maxims, but with more experience I feel like the
| story of requirements is overlooked. When requirements were
| static from the beginning and easy to understand for all parties
| you can get good code. It kind of exists in a bubble of
| stability. And when you reach for it again the stableness is
| unchanged so you just forget about it and it becomes part of the
| background noise. Much of the time the tech debt and weirdness of
| codebases I encountered in the wild is a reflection of an untold
| story of how requirements changed and miscommunication between
| the parties involved
| zoomablemind wrote:
| Generally, I think of programming as about managing complexity.
| Simplifying and ranging the tangled objectives, tying loose ends
| and integrating with even more complex systems.
|
| So, naturally, as one progresses in the field, the level of
| complexity often increases with experience. Sure, some tasks
| become easier, but those are getting assigned to 'juniors' or
| just are no longer interesting...
|
| Here it is, more experience, yet still uphill with complexity. It
| does get tiring at some point.
| scop wrote:
| > The programmer, like the poet, works only slightly removed from
| pure thought-stuff. He builds his castles in the air, from air,
| creating by exertion of the imagination.
|
| - Brooks, Mythical Man Month
|
| I always take inspiration from this quote, both when times are
| good and when times are bad. When programming is easy, ah how
| just like glorious poetry it can feel. Natural and easy. When
| programming is hard, boy what exertion it can take to wrangle
| thoughts and ideas. Writing poetry when the creativity isn't
| there, whatever _it_ is, is just torturous.
| oglop wrote:
| I really enjoyed this and it has lots of great lessons.
|
| One small point though. I noticed this paragraph:
|
| "From a certain perspective, software is inherently designed to
| be modified (why else would it be called "software"?). This makes
| developing software fundamentally different from building houses.
| After all, nobody would say after constructing a building, "Let's
| knock it down and rebuild it! The same structure but with 30%
| less steel and concrete!""
|
| It's odd to me the author doesn't see the connection from the
| instance of the software and the code. In this example, the
| instance is the house and the code is the blueprint. Code and
| blueprints change ALL the time. So I think it is false to suggest
| software engineering is somehow different from other engineering
| disciplines. I'd say it's exactly the same but with a whole lot
| less ethical considerations, largely due to reasoning like above.
|
| Great read, I just had to point that out though.
| ericyd wrote:
| > As "wordsmiths," programmers often neglect reading. However,
| reading is an essential part of quickly improving your
| programming skills.
|
| I'm always surprised to hear that most programmers dislike code
| reviews. I've found code reviews to be one of the most useful
| ways to learn new design patterns and language features. I
| personally believe that adopting a mindset of curiosity helps
| make code reviews enjoyable rather than tedious.
| mrozbarry wrote:
| The biggest thing is people have bad experiences with
| reviewers, and people have a lot of insecurity when their work
| is scrutinized.
|
| The biggest issue with code reviews as a process is it's always
| positioned as being adversarial. Often, you set up a pull/merge
| request, and someone later does a review, but it's not
| personal, it's cold and blunt data. Even with a reviewer who
| has the best intentions, it's tough.
|
| Pair programming and review can _help_ with this. Sit with the
| person who wrote the code, and review together.
|
| I'm with you, code reviews are great for learning, but like you
| said, you need to see it as a tool to help you succeed and
| learn, and not as a tool to show you how you're wrong.
| polishdude20 wrote:
| At a previous place our code reviews just turned into a quick
| glance at the code without a real understanding of anything.
| On one hand I'd like to say it was built on trust in the
| engineer and test suite, on the other, there was just so much
| complication and tediousness in some things we did that it
| was hard to know what was going on in the first place.
| elwell wrote:
| Is 14 years a lot still? I'm 35 with ~14 years (but really coding
| since middle school); just trying to figure out if I'm officially
| old?
| aw94jaw94 wrote:
| I'm happy to say that my company writes "good" code, at least on
| the production side, and I have genuinely learned a ton and
| become a better engineer while working here. The experimental,
| test, and sometimes CI code is shit. Test code makes sense, it's
| immature prototype. CI should be much better than it is, it's
| extremely fail-safe and its false-positive rate is a major
| headache for the entire software org. But our production code is
| genuinely very good. You won't get a PR merged with literals in
| code or custom functions that could be replaced by STD functions
| or unnecessary copy operations, or without thorough design
| documentation and comprehensive unit tests and CPU load test
| results and a review of the effects of your change on near and
| distant stakeholders. (Our code could literally kill large
| numbers of people, so it's a good idea to maintain these
| standards.)
|
| Previously I worked for half a dozen early-stage startups that
| wrote super-janky demo code that would have to be power-cycled
| multiple times to get to a fully operational state and no one at
| the company had more than a year experience outside academia so
| founders didn't see a problem with that level of reliability. In
| those roles I learned a lot about math and dealing with giant
| egos, but not much about software engineering.
|
| Point is, there are companies who rigorously enforce good code
| requirements, where you can learn from others and improve your
| skills, where "good code" is the norm.
| elwell wrote:
| 'difficult' is relatively meaningless, or I guess _only_
| meaningful relatively. Basically once you know something (e.g., a
| particular leetcode problem, or how to paginate an API) it 's
| easy all of a sudden, but it was hard before you knew it.
|
| The more interesting endeavor is to make the complicated simple.
| beryilma wrote:
| Programming is a grossly general concept that doesn't really have
| a precise meaning anymore, if it ever did. Especially these days,
| programming is associated with developing CRUD or web
| applications, which make it sound like an easy thing to do and
| which is relatively easy, at least conceptually.
|
| However, programming will be hard if the thing that you are
| programming for has enough (essential) complexity and there is no
| way around it, even if you are experienced. Some examples where I
| found programming to be very hard include
|
| - Programming a microcontroller that has a 1400-page reference
| manual and many conceptually difficult things that you would have
| to manage.
|
| - Taking pseudocode of an algorithm from a research article and
| turning it into professional, commercial code while handling all
| the edge cases that were never considered in the article. I
| believe it was Donald Knuth who claimed that the correct
| implementation of some 50-line sort algorithm took 30 years to
| get it finally right.
|
| - Constructing the state machine of a complex-enough system and
| implementing it in code. Take David Harel's Statechart paper, for
| example, where he builds the state chart of a "simple" Casio
| wristwatch. Building such a state machine and implementing it in
| code will always be hard, even if you have more modern tools.
|
| So, to reiterate, programming does not just mean downloading some
| npm library and making API calls to it. When I see comments like
| "Programming now for 30 years and it's a breeze to pick up new
| frameworks and ideas", I wonder if people have a very narrow
| definition of what programming is.
| jedisct1 wrote:
| I find programming _more_ difficult now.
|
| "But wait, you have more experience and we have better tools!"
|
| Yes, but programming stacks used to be simple and well-defined.
|
| HTML/CSS/jQuery + a LAMP stack or ROR could get you a long way.
| Baring IE bugs, it was possible to 1) develop without constantly
| using Google 2) understand what every line of code does 3) be
| quickly productive, which was very satisfactory.
|
| These days, starting and deploying a new project involves a
| kitchen sink with a bazillion tools, languages and 3rd-party
| dependencies. And when something doesn't work the way you expect
| it to, it's a ton of work to find the needle in the haystack,
| with so many layers to understand, especially since they don't
| share any consistency whatsoever.
| paulpauper wrote:
| _Programming languages are also becoming more user-friendly.
| Classic languages like C and Java are no longer the first choice
| for most beginners, and many simpler, more accessible dynamic
| languages are now popular. The IDEs and other tools have also
| improved. Together, these factors lower the learning curve for
| programming._
|
| I doubt it. Nowadays to start programming you need to set up
| complicated run environments and other setups even before you
| begin to code something. Programs are more complicated, such as
| apps which involve front-end and back-end. These games that claim
| to help with programming only hide the actual programming or
| abstraction . People think they are coding but are not really
| coding. Moving boxes around is not coding.
| szundi wrote:
| Thanks god it's not boring
| neilv wrote:
| Great points, and I'd like to call out one section in particular:
|
| > _What is good code?_
|
| Missed one that really needs to be articulated: _Correctness_.
|
| Poor correctness is one of the most harmful and widespread
| problems in software today.
|
| Even one of the most wealthy and best-paying companies cannot
| manage to deliver an acceptable level of correctness for some of
| the most widely-deployed Internet-facing software:
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
|
| And that company is arguably better at software engineering than
| the majority of companies.
|
| The takehome _isn 't_ "even Google makes software littered with
| critical defects, so I guess that excuses everyone else, lol".
| But rather, that most of our engineering field hasn't been held
| responsible for correctness, and now we routinely knowingly
| deliver engineering work that we assume has critical defects. And
| we show no remorse: even when some software is routinely shipping
| _multiple security vulnerability patches per week_ , we keep
| doing the same shoddy engineering, sustaining the gushing
| pipeline of vulnerabilities needing patching.
| rsrsrs86 wrote:
| Well programming IS difficult. And a senior developer knows it.
| It's easy enough to master C++ in a year, but ten years are not
| enough. So zen. What I mean is if you know your language enough,
| you will sometime realize you never know everything.
| Frummy wrote:
| I really, really agree. I learned programming on leetcode and
| took the short feedback loops and automated tests for granted.
| Then working on legacy software on legacy hardware without
| automated tests and lots of interactions with other programs and
| databases, that was a shocking reality check.
| polishdude20 wrote:
| Enter modifying your local database manually to set up your
| state so you can then run a test by hand to see if your thing
| didn't break other things
| cyrialize wrote:
| I think the hard part of programming, or programming related
| things, is environment setup.
|
| Even with things like Docker, you can still run into SO many
| issues.
|
| Programming by myself is always easy.
|
| Programming within a company can be difficult because of this.
| There are definitely places out there that make environment setup
| super simple. Even then, you can still run into something that
| hasn't been encountered before.
| polishdude20 wrote:
| Also just slow, fragile environments once they are set up.
|
| At a previous place I worked, tests would be slow, builds would
| frequently break and you had to recite the correct incantation
| of commands to fix them again. We had a common saying: whenever
| someone would say their build process is broken, we'd say "ah
| you must have pulled master".
|
| Environments that are fast, stable and get out of your way are
| a godsend. Unfortunately when working in a monolith, everyone's
| special build changes are shared with everyone else. Then those
| build changes break things.
| ein0p wrote:
| This is the problem as old as time. For one thing as you gain
| more experience your experience is deployed on gnarlier, more
| poorly defined tasks, which are naturally more difficult. For
| another, as yoy get exposure to higher level concerns you begin
| to care about them more. So no wonder it doesn't get easier -
| hopefully the paycheck gets fatter over time
| coolThingsFirst wrote:
| Working on big projects is difficult af.
|
| The context width required for programming exceeds that of normal
| human beings. There is just A LOT of stuff to keep track of, it's
| not logic that's difficult that's the easy part.
| polishdude20 wrote:
| Do you have any methods for keeping track of all the context? I
| usually go for a flowchart app and flowchart all the things and
| systems in order to better understand what's happening. I find
| the act of writing the flowchart actually helps me more than
| having a completed one.
| thatfatboy wrote:
| everyone find it difficult whether they know it or not because
| there are no bug-free software yet.
| MarkSweep wrote:
| A lot of these points are why I still enjoy programming as a
| hobby, but less so enjoy it as a profession. It is much easier to
| program something where you are the only customer. No project
| manager alternates between asking me increase and decrease the
| number of story points per task. No one comes with a last minute
| request to create a throw away demo for some executive who can
| only understand pointy-clicks things.
|
| Directly addressing the title, one thing I still find difficult
| in programming is implementing an informal parser. Think calling
| read(2) and parsing an HTTP request. Making something work with
| partial reads and multiple buffers is tricky. I really should
| reach for a real parser sooner in these situations is the actual
| answer and stop trying to work at such a low level of
| abstraction.
___________________________________________________________________
(page generated 2024-02-23 23:01 UTC)