[HN Gopher] Many software companies are a joke
___________________________________________________________________
Many software companies are a joke
Author : openplatypus
Score : 403 points
Date : 2022-05-16 08:12 UTC (14 hours ago)
(HTM) web link (liou28335.medium.com)
(TXT) w3m dump (liou28335.medium.com)
| Negitivefrags wrote:
| The sad thing is that it's a joke that many people don't seem to
| be in on.
|
| You get all these defenders coming out of the woodwork when
| people wonder what the hell all the programmers at say, Twitter,
| are doing. Supposedly you puny mind can't comprehend the
| challenges of developing a website "at scale"
|
| The real answer is, almost nothing. People are being paid very
| high salaries to do nothing.
| bigDinosaur wrote:
| Nah, most people feel some guilt at doing nothing when they're
| paid well, so my guess is lots of internal projects that don't
| go anywhere and that we never hear about. That's quite
| different to nothing at all.
| Negitivefrags wrote:
| Oh I'm sure that it _feels_ like they are doing something.
|
| But in a badly managed company each person is like a randomly
| oriented vector.
|
| You sum them together and the end result is something near to
| zero.
| barrenko wrote:
| It goes to minus something imho, wherein lies our problem.
| BeFlatXIII wrote:
| > People are being paid very high salaries to do nothing.
|
| I'm patiently waiting for some kind of deep-dive historical
| monograph to be written in the 2050s. What I suspect may have
| happened is that these companies overhire top talent simply so
| their competitors can't have them. For the actual work they do,
| it's massively overpaying. As a strategic investment to prevent
| said talent from working elsewhere or starting their own
| business, perhaps it pays off.
| knotofvipers wrote:
| I am not sure it is even that rational though.
|
| I think it is like brand name vs off brand. I just bought off
| brand oatmeal that was $1.98 vs the brand name was $3.50.
|
| Someone buying the brand name is just operating on an
| unthinking heuristic that they only buy "the best". I am sure
| they would justify it after the fact that the brand name
| taste better even though it is just oatmeal.
|
| So many decision points in society run on that heuristic IMO.
| baybal2 wrote:
| > The sad thing is that it's a joke that many people don't seem
| to be in on.
|
| On each of my job in my early career, I spent considerable
| effort weeding out people who got too used to such mode of
| work.
|
| There are software developers with vastly different prior work
| experience, and expectations. People who do 30 minutes of
| actual coding a day, and ones who do 11 hours in coding
| sweatshops.
|
| People who spent their entire career on 30 minutes of coding a
| day jobs, and think of themselves too much once they rise in
| seniority are the worst, and are the biggest source of dumpster
| fire/death march projects.
|
| My third serious job in Canada: work in a consumer electronics
| trading company, upgrading their shipping system to get
| shipment status from DHL API, and submitting new ones. My
| predecessor, and ex-unit head wasted close to $1m, and more
| than a year, got SAP involved, invited many consultants, change
| managers, a project management contractor, and just been in the
| process of "fixing deficiencies" of his work by buying
| "enterprise SOA solution."
|
| 23 year old me called this bullshit on the second week, fought
| to have a serious talk with the company owner, rewrote a 10
| years old steaming pile of PERL, and BASH scripts to Python,
| Postgres, and JS frontend in under one week, showed it working,
| and countered "You don't understand SOA!" protests of the unit
| head in front of the boss. He gets fired, I get a bonus the
| size of my annual salary.
|
| Since then, my bosses always threw me as a "firefighter" on
| projects in crisis.
|
| ------------
|
| We now have 2 major trends in the industry:
|
| 1. More, and more non-IT companies are trying to do software
|
| 2. A giant amount of newcomers to the industry who would've
| normally went working for banks, and management consulting
| companies eroding big IT companies as later grew with little
| regard to quality of hires.
| mesozoic wrote:
| But I'm encouraged to take a project it would take me a day
| or two to do and give it to a junior engineer to take weeks
| on it so they learn.
| fy20 wrote:
| How do I get in on this? For the 10 years I've been in this
| industry I've never been in a job where I felt like I had it
| easy. It's always been a rush to get one project done then
| there's always something else in the pipeline. Whether those
| projects are actually worth doing is a different question...
| Jensson wrote:
| Manager pay correlates with how many reports they have. So
| all of them are incentivised to making it look like their
| team is spread thin, so even if you don't have to work hard
| he will make you work hard so that he can tell his manager
| that he needs more headcount.
| commandlinefan wrote:
| > a job where I felt like I had it easy
|
| They don't have it easy either. They have to demonstrate at
| least once a year that they've "accomplished" something in
| spite of an entire organization of gates that make
| accomplishing anything nearly impossible. But they still have
| to figure out a way to do it, and it still has to be somehow
| represent enough to justify their pay.
| mike10921 wrote:
| It might sound exciting but its actually super depressing.
| You get paid mad $$ and in ur head ur think "what the ef are
| these idiots paying us for?". I ended up leaving just because
| it made me feel so useless i couldn't handle it anymore.
| akvadrako wrote:
| Become a contractor or even more so a consultant. You'll
| often find yourself on dysfunctional teams where management
| barely knows what they want and things often never get done.
|
| I wouldn't recommend it though since it's soul crushing.
| cmrdporcupine wrote:
| Careful what you wish for. It's not "easy" at places like
| that. It's just different. Instead of your work being keeping
| a system up and running putting out fires or implementing
| features or coming up with algorithms on a tight schedule...
| it's, instead: figuring out who is doing what, what you're
| supposed to be doing, what permissions list you need to be on
| in order to access X system, asking to be on that list and
| waiting, submitting a minor feature to code review that takes
| a week to go through because someone didn't check their
| email, rewriting a major part of the code in that review
| because someone came in at the last minute and didn't like
| some thing about it that was actually decided on weeks ago
| but they weren't looped in.
|
| The amount of actual lines of code written by an _average_
| SWE at a BigCorp is miniscule. The amount of churn and
| spinning and hand wringing that goes into that code is
| staggering. But it 's like that _for a reason_. There 's just
| a lot of people.
|
| It's torture, and in order to maintain productivity you need
| to have about 5-6 of these processes running concurrently,
| and it's why you get paid a lot of money to do it.
|
| Do poorly at juggling that and making "progress"? Find
| yourself on the receiving end of a performance review where
| the label "meets expectations" _actually_ means "you better
| start kicking ass at this, or you'll find yourself with no
| stock refresh grants for next year."
|
| All the money and free food and so on is just a salve to try
| to make the whole thing less unpleasant. Some people get a
| high out of the process, while it drives other people slowly
| crazy.
|
| (In my last months at Google the only part of the job I
| "enjoyed" was the week I was on-call for the first time on my
| new team. Because it was the only time in over a year where I
| felt _useful_ even though it was quite stressful. That 's how
| I knew it was time to pack it in)
|
| https://goomics.net/364/
| ratww wrote:
| Yep.
|
| With an addendum: it's not that they do "nothing", and that's
| the "problem". The end result is minimal, but the amount of
| work is still significant.
|
| In any saner place it would amount to almost nothing, but for
| certain companies it is an Herculean task. And developers know
| it.
|
| However due to the fact that the company hired thousand of
| coders, their communication overhead is now too massive. Their
| architecture also suffers due to the needs of handling those
| thousands of developers, so there's also a lot of work to be
| done in coding.
|
| But the pressure is still there. Why hasn't your team changed
| the color of the button yet? "Why is it so hard?", "Why is it
| taking so long", etc etc
|
| Jokes have been made about it:
| https://www.youtube.com/watch?v=y8OnoxKotPQ
|
| The answer to all that was known since the 70s. Fred Brooks
| wrote a great book about all that.
| bo1024 wrote:
| > to do nothing
|
| The author puts it better: they do lots of things, all day
| long, but produce almost nothing.
| commandlinefan wrote:
| > People are being paid very high salaries to do nothing.
|
| People are being paid very high salaries to be frustrated by
| explicit prohibitions on doing anything. Nobody gets to being
| good enough to be hired by a company like Twitter if they don't
| actually _want_ to do real software development - management
| exists to crush that desire and ensure that nothing ever gets
| done.
| mike10921 wrote:
| Yup i recently worked at a company that had a lot of their base
| technology already built out. They hired a lot of new expensive
| talent and the talent was pretty bored so they made a big
| project to re-do all the existing technology that already
| worked pretty well. The results are less than good..
| pyb wrote:
| This ongoing debate on productivity at small startups vs large
| companies will never be resolved by argumentation. But as we
| can see from this thread, corporate engineers overwhelmingly
| outnumber early-stage startup engineers. Therefore, they tend
| to "win" the debate by being louder.
| lupire wrote:
| The other thing about big corps is that they work on stuff
| that actually matters to customers for a long time, not "Our
| Incredible Journey" demo software intended to be rug pulled
| as soon as the founders get acquihired.
| EdwardDiego wrote:
| There's scale, and then there's _scale_. And I can happily
| believe that Twitter is working at the latter.
|
| It's like something like AWS or Azure. You can provision and
| deploy a K8s cluster? Awesome! Now, can you do that
| consistently for the next 100 thousand K8s clusters you're
| selling to your clients?
|
| It's a very different kettle of fish.
| pc86 wrote:
| I think regardless of scale, spending over a year working on
| edit functionality is endemic of _something_ being horribly
| wrong organizationally. Maybe it doesn 't even involve the
| software engineering groups (though it probably does). But
| that's simply not something that takes even a fraction of
| that time in a healthy organization.
| _fizz_buzz_ wrote:
| That's what I am thinking. E.g. I am looking at lichess which
| has a massive user base and is developed by one full time
| developer and a few dozens volunteers. Twitter is obviously
| bigger, but I simply don't buy that you need more than 7000
| people to run that site.
| ZephyrBlu wrote:
| Maybe you don't need 7000, but software is even worse than
| icebergs (Only 30% visible). How many people at Twitter are
| there to fulfill functions we aren't even aware of?
| Compliance, privacy, legal, internal tooling, etc and god
| knows what else.
|
| My experience at a tech company with around the same number
| of employees is that it actually feels _understaffed_ in some
| of the areas I 've seen. It's surprising how much
| responsibility some teams have.
| BeFlatXIII wrote:
| Honestly why I'm considering _not_ starting my own
| business. Getting the product to work is the first 80% of
| the work. The remaining 96% is billing, authentication, and
| marketing.
| ratww wrote:
| The whole reason it feels understaffed is because there's
| too many people.
|
| I know it sounds counter-intuitive, but software doesn't
| really scale linearly. Unless they're 100% independent, the
| communication overhead will always be there. Fred Brooks
| and all that.
|
| With 7000 developers working in a connected system, it
| probably feels slower and less things get done than if
| there were less people.
|
| It's not simple to go back to having less people, however.
| The architecture is most certainly tied to the
| organizational structure (Conway's Law), and firing people
| will make it worse in the meantime.
| ZephyrBlu wrote:
| Please elaborate. It doesn't feel understaffed because of
| communication overhead or being in a connected system,
| but because of the level of responsibility (I.e. critical
| system) or product surface area a team is responsible
| for.
| ratww wrote:
| Sure. The things you mention (Compliance, privacy, legal,
| internal tooling) also have to grow together with the
| number of developers to scale. Not only those, but also
| support, QA, management, UX/UI. All those ares have to
| increase when the dev headcount increases. But since most
| of those need some degree of centralization and
| coordination, they can't escape communication overhead
| and orgs slow to a crawl.
|
| Also, software development teams have to assume _more_
| responsibilities just to escape this communication
| /interconnection overhead: devops is a good example, you
| no longer have to depend on another team, but now you
| gotta do operations yourself. An example of avoiding
| interconnection overhead is having isolated services: now
| you don't run queries on team Y's database, but you still
| have to maintain that data on your own DB. Isolation is a
| good alternative, but it also has its costs.
|
| Unless we're talking about 7000 software developers
| working on 400 completely different and completely
| isolated products and answering to different people,
| there's gonna be a lot of invisible communication
| overhead, or overhead because of the need to work
| together with the other 6999. We developers tend to
| abstract it as being "part of the job", even though it is
| definitely non-essential complexity.
|
| Even consulting companies doing different projects can
| fall prey to that: I know lots of cases of internal
| frameworks/libraries/UI-toolkits being adopted to
| accelerate development, but they ended up being a
| bottleneck in development because the team that owned had
| a full backlog.
| ejb999 wrote:
| I have been an independent consultant for almost my entire
| career - working with clients large and small, mostly on solo
| projects.
|
| Took a FT job at a megacorp a few years ago and assigned a
| new project - I read the specs/requirements and in my IC mind
| thought to myself - if I was hired as contractor to develop
| this tool, how much would I charge? and how long would it
| take me? - and came up with 1 person, for 2 months, and would
| have been delighted to be able to bill $40K for it, but
| probably would have went it at $60K on a fixed bid (I always
| preferred fix bids).
|
| Of course this wasn't a project I was bidding on, I was just
| the lead dev - the company pulled together a team of almost a
| dozen people and a budget of just over a million dollars with
| a 8 month timeframe to get it done - they also budgeted
| another $120K/year to host it when it was done on multiple
| big servers in the internal data center.
|
| We spent the full million dollars and got it done - I did
| however have one small win and pushed them to micro-services
| solution in S3 and Aws Lambda and got the whole thing to run
| within the free-tier of an AWS account.
|
| If you ever start a small software company, don't ever hire
| people that have only worked in large enterprises - they just
| don't know how to get things done cost or time efficiently.
| ketchupdebugger wrote:
| Companies like twitter operate at a different scale. Lichess
| can off load hiring devs by using out of box solutions like
| paying for AWS, paying for cdn, using adsense to serve ads,
| utilizing thirdparty libraries, etc. For large companies, a
| lot of these are in house solutions, because at that scale,
| it could be cheaper, they wont as dependent on other
| companies for reliability, they have more control over where
| the data is being used or stored. etc.
| bowsamic wrote:
| cmrdporcupine wrote:
| As I commented elsewhere. They're not doing nothing. They're
| maintaining the organization. In a large company with a service
| that needs to be reliable, doing things quickly can result in
| things... breaking quickly and causing headaches when there's
| no consensus, etc. So everything needs to be done slowly and
| carefully and looping in dozens of people even for small
| trivial things. It sucks working this way, so they have to pay
| a lot for it.
| reallscoliosoi wrote:
| It is funny because people who are unemployed are shamed for
| being "unproductive members of society", yet when you get out
| into the real world, you see all of these people doing nothing
| and getting paid lots of money, which is even worse than being
| unemployed in that context.
|
| Anyway, it seems there is just a lot of money to go around and
| political and social favours dominate a lot of the decisions.
| ethbr0 wrote:
| Free market capitalism is the least efficient allocator of
| work and pay, except for all the others.
| t-3 wrote:
| Free market communism is probably more efficient, it just
| requires the kind of socioeconomic conditions that attract
| invasions from capitalists.
| ethbr0 wrote:
| Free market communism as in? Free market economy with
| communist political system and allocation?
|
| Trying to parse your definition of the term, as it seems
| like any definition for communism disrupts the feedback
| mechanism that is a free market's primary (only?)
| advantage.
| t-3 wrote:
| Not all communism is authoritarian/statist. "Libertarian
| communism" (sometimes known as anarchy) is socialist
| while allowing freedom of association and economic self-
| determinism. Historically, it has been strongly linked to
| the concept of republicanism and unions.
| ethbr0 wrote:
| What part of it is most socialist? (Honestly asking and
| curious, I'm terribly ignorant in the more niche -isms of
| potential political-economic organization)
| t-3 wrote:
| It's socialist in the sense of promoting mutual aid and
| communalism. The union movement was originally very
| influenced by these ideas. Unions, co-ops, FOSS projects,
| and community organizations are good examples of these
| type of political/economic structures.
|
| If you're interested, Peter Kropotkin wrote a lot of
| books and pamphlets that are freely available.
| lupire wrote:
| Free/Libre software is free market communism.
|
| It's a free market but with the financial incentive
| system removed, but maybe social/status/religious
| incentive retained. Everyone does what they want but at
| 100% tax rate and the product is shared. Of course this
| only works in IP because it has zero marginal cost of
| consumption (and taxation!). In meat space you have the
| political problem of how the fruits of labor are
| distributed.
| Jensson wrote:
| Who pays the developers of said software so they don't
| starve? The state? Then the state will decide what
| projects gets traction, such centralized planning is the
| main reason communism fails. Software engineers would
| then be more like scientists having to spend most of
| their time writing grant requests to motivate why they
| should get any pay, I really doubt this would give
| society better software compared to the current free
| market solution.
| gmm1990 wrote:
| you could have a ubi system and then add incentives for
| devs on open source products that are used. Just a
| thought, I'm sure there would be corruption of this
| system too
| ethbr0 wrote:
| Or the same thing, slightly differently, who uses FOSS?
| For-profit companies.
|
| I think history has born out how FOSS incentives get
| entangled with a primary and majority patron.
| achow wrote:
| There seems to be unnecessary vitriol towards the author.
|
| What he mentions about big financial companies (where software
| are for internal workflows) that is the life, and there are many
| of them and they are usually big employers.
|
| And what he says "You see, we were always busy but seldom
| productive" is actually the essence of 'Mythical Man Month'.
|
| About FAANG/MAANG, I have seen brilliant college toppers mucking
| around with html tags (but not able to get them right).
|
| High salaries to a lot of software worker is a joke indeed.
| zcbenz wrote:
| I feel really sorry for the author, what he said does not
| deserve such mean comments.
| johncessna wrote:
| After working at several large $techCompanyAcronym companies, I
| agree with the author's premise, but I don't agree that the time
| gets wasted in planning/bickering over color palettes. I also
| don't agree that there's a CYA culture in large companies, at
| least not at the front line worker level.
|
| Here are a few issues I see:
|
| A lack of achievable goals. They tend to be massive multi-year
| long initiatives. It's hard to feel any sort of urgency from a 2
| year project. Even if it's broken into 6 month long chunks, it's
| hard to feel urgency given if you slip the first milestone,
| you've still got 1.5 years to go. Additionally, large projects
| suffer from analysis paralysis. I don't think this is a malicious
| thing, I think folks genuinely don't know what it is they need to
| do.
|
| It's easy to hide in a large company. Generally, the longer it
| takes you to be productive the longer you can do nothing before
| getting noticed and/or actually terminated. An 8-12 month ramp up
| time is average in my experience. When the company only has 20
| engineers it's easy to find the ones not pulling their weight.
| When you have 100k engineers, it way harder, and stack rankings,
| and the resulting hire-to-fire, are put into place.
|
| Mandatory and optional training and non-work related events
| consume a lot of time. By non-work I mean things not relevant to
| the team's objectives. One could easily do nothing by
| participating in all the summits, trainings, meetings, wellness
| events, interviews, debriefs, design reviews, security reviews,
| etc.
| batiudrami wrote:
| Astonishing to me that someone with 20 years' experience in any
| industry could have so little perspective. Obviously there are
| inefficiencies with big companies, but complaining about needing
| to do documentation, or basic project management?
|
| The writing is smug and shows no self awareness - it seems to me
| that the author cannot recognise that there may be other
| priorities than exactly what is in front of them and therefore
| everyone who disagrees with him must be wrong.
|
| It is good that the author has found something that suits them
| better.
| caseymarquis wrote:
| I think this is a little of column A and a little of column B.
| Just as there are good and bad developers, there are people who
| are good and bad at running projects and organizations. The
| author feels that something is wrong. He knows he is not
| working anywhere near his full capacity and that the
| organization created this environment. He also highlights a
| lack of growth opportunities at some companies. What he doesn't
| do is highlight solutions or recognize why certain behaviors
| are key in certain environments.
|
| Toward that end, I would recommend three old and poorly written
| books with timeless and wonderful ideas: The Goal, Critical
| Chain, and Managing Corporate Lifecycles.
|
| While these books are all about management and running a
| company, I think they lend perspective to developers on why
| certain things happen the way they do. They can also help
| someone recognize and pick a healthy organization to work in.
| Just like books on software development, these books augment
| experience, they don't replace the need for it.
| Dave3of5 wrote:
| I agree that the tone of the article is off but I don't agree
| with this statement:
|
| > Obviously there are inefficiencies with big companies, but
| complaining about needing to do documentation, or basic project
| management?
|
| This sounds like you've never been in a big org where you write
| more word docs than you do code. I have. It was terrible for a
| few reasons:
|
| * Those docs go out of date with the code very quickly and so
| are not a good reference to what the code actually does
|
| * They eat up a lot of project time and so projects tend to
| become late. As the documentation is what you have to write
| first by the time you get to the code you have much less time
| to actually write the dam code
|
| * Extreme documentation actually reduces code quality. I've
| worked on many code bases where the code actually references
| page numbers and sections rather than what it actually doing.
| This is often the case with contractors that are only on
| project for a short amount of time and thus translate the docs
| directly into code. Also if there are and errors when creating
| these docs they are often translated into the code often into
| performance / non-functional problems
|
| * Docs written after the fact end up being rather pointless /
| unusable as you'll have to describe all the weird things you
| done to make it work properly / fast ...etc
|
| * Non technical people will read what you've written not
| understand it, because it's highly technical, misinterpret it
| then use that strange idea of things they've got all over the
| place. Like someone that doesn't know what a Foreign Key is but
| seen it once and sticks them on every column in the DB. Then
| you'll have to have a fight with them as "it says here on this
| doc"
|
| I could go on but I suspect what I've written here is quite
| unpopular so I'll end by saying that documentation is very hard
| to write correctly you need specialists who know exactly how to
| describe what's been done in the system to others. You also
| need to balance the amount of docs you create vs the actual
| work on creating the thing.
|
| Again on Project Management you described it as "Obviously
| there are inefficiencies with big companies" that sounds like
| you've never been in a full 8 hour days worth of meetings
| getting 0 coding done and just explaining to 10 different
| managers what needs to be done. Some of these big corporates
| are so colossally inefficient that people have been quitting on
| mass during the pandemic to get away from it. It's a serious
| problem not just to be swept under the rug like oh well that's
| just what big companies do. I heard someone either on reddit or
| on here defend a 3 hour long "daily standup" meeting because it
| was good to know what the devs are doing. Like yeah there are
| in you meeting for 1/2 of the day.
|
| Now I don't condone 0 project management but companies
| seriously need to cut it back. Tools like Jira have made
| working hell for some programmers.
| jokethrowaway wrote:
| I'm pushing more than 15 and feel like the author is right.
|
| What you're missing is that doing soft tasks is a tradeoff and
| big companies are leaving a lot on the table by having an
| inflexible culture.
|
| Those same big companies will end up buying startups for 10x
| their ARR to get some mediocre product with no documentation or
| tests, cranked by developers on redbulls swearing at each other
| instead of doing retrospectives and yoga friday.
| batiudrami wrote:
| I understand the trade off, and big companies do too. You're
| going to lose a lot of very talented staff because that is
| the work environment doesn't suit them. It is a trade off
| companies make because they are managing risk, and because
| they have other priorities than having software coded at the
| fastest possible speed.
| mschuster91 wrote:
| > Those same big companies will end up buying startups for
| 10x their ARR to get some mediocre product with no
| documentation or tests, cranked by developers on redbulls
| swearing at each other instead of doing retrospectives and
| yoga friday.
|
| And yet, that mediocre product still is orders of magnitude
| better than what the big-co would have been able to produce
| internally, simply because of all the ass-kissing and butt-
| covering involved in big-co office politics.
| WesolyKubeczek wrote:
| > but complaining about needing to do documentation, or basic
| project management?
|
| I think you missed the point about documentation and project
| management taking inordinate amount of time and manpower
| compared to the output in both quantity and quality.
| turing_complete wrote:
| Can you point out where he is wrong, though? His criticism
| might not be true for all teams in all large companies, bIt
| I've worked at one of the FAANG companies and left for the same
| reasons. And I know similar stories from friends and ex-
| colleagues.
| ineedasername wrote:
| That's fair, and given the tone I wouldn't be surprised if
| there were some very exaggerated #s there. But if accurate 1-2
| hours a day of coding on average is pretty bad. Meeting etc are
| necessary but it shouldn't be that bad.
| remus wrote:
| Yeah, it's a strange article. They seem to miss the underlying
| point that in a business, generally speaking, writing the code
| is relatively easy. It's working out what problem you're trying
| to solve and who you're solving it for that is the hard part
| (an the bit that requires you to spend time talking to other
| people). Of course you write more code working on your side
| project, because you know exactly what you want to do with it
| and there's usually no consequences if it goes wrong.
| blowski wrote:
| The problem with the article is that it's the perspective of
| an engineer who hasn't had to think about higher-level
| problems. If I had to summarise their perspective it's "if
| engineers are writing code, that's a good thing, and anything
| else they do is probably a waste of time".
|
| But what if engineers are writing bad code? What if their
| code doesn't solve any customer problems? What if the other
| thing they're doing is helping them write better code? Or
| scaling the company so they can hire other engineers who do
| write better code?
| sirwhinesalot wrote:
| We've figured out 20 years ago that writing code, showing
| the resulting program to customers and getting feedback was
| the most effective way to find out if you're actually
| solving customer problems. Some group of people wrote about
| it in something called the "Agile Manifesto" or some such.
| blowski wrote:
| How do you think an author of the Agile Manifesto would
| respond to the original article?
| sirwhinesalot wrote:
| Considering how companies are implementing the "Half-
| Arsed Agile Manifesto" rather than the actual "Agile
| Manifesto", I think reading this article might be what
| pushes them to jump off a bridge. 20 years of companies
| failing to understand your 4 line text, and using it to
| justify things that are utterly antithetical to what it
| stood for, has got to hurt. It's so simple:
|
| - Individuals and interactions over processes and tools
|
| - Working software over comprehensive documentation
|
| - Customer collaboration over contract negotiation
|
| - Responding to change over following a plan
|
| Sounds like an environment the author of the post would
| like, he even describes such an environment later on, one
| that he enjoys so much he overworks for no extra pay.
|
| Then there's the twelve principles, one of which is:
|
| "Working software is the primary measure of progress."
|
| Another one is:
|
| "The best architectures, requirements, and designs emerge
| from self-organizing teams."
|
| Another is:
|
| "Build projects around motivated individuals. Give them
| the environment and support they need, and trust them to
| get the job done."
|
| Following bullshit company processes and pointless
| meetings is the opposite of the above. The one that might
| be contentious is:
|
| "Business people and developers must work together daily
| throughout the project."
|
| This sounds a lot like meetings, but that's the
| smallbrained take on it. Here's an easy alternative:
| Continuous Deployment in a staging area and a Slack/Teams
| channel for business people to comment on changes they
| feel are necessary. Not only does the request get
| recorded (often nothing gets documented in meetings) but
| the communication is asynchronous and doesn't require
| booking the entire team for hours. The discussion is also
| a lot more actionable because it is about something
| concrete.
|
| Given the above, what do you think about how an author of
| the manifesto would respond?
| blowski wrote:
| I imagine the author of the original article works in a
| company which is prioritising the right hand of the
| principles over the left. We've all worked there, we've
| all hated it. I did, so I set up my own company where
| we'd do agile right.
|
| Hired my own team of devs. Got no revenue, velocity was
| low. Ended up annoying all the devs by trying to push
| them to spend more on the right-hand side of the
| manifesto than they thought was necessary so I could
| figure out why nothing was getting done. Still got no
| revenue. Eventually gave up.
|
| I think the authors of the agile manifesto would say that
| building complex software requires the business to adopt
| agile (real agile, not half-arsed agile) with the tech
| team subsequently following it. The engineers also need
| to deliver on their side of the bargain. That means
| continous value, and not just fiddling with shiny new
| tech and fancy design patterns. When both sides of that
| operation work well together, you get good software. If
| you've got enough good people that already know how to do
| this, it bodes well. But how do you find and pay for all
| these good people? That's why you get people that merely
| think they're good, but are at least much cheaper.
|
| The engineering tendency when given freedom is to over-
| engineer everything, leading to disappointed clients, and
| a fragile system that's buggy and can't be fixed. It's
| one of the big reasons so many tech-led startups fail,
| and also why bigger businesses end up putting all these
| bullshit processes in place.
|
| And that's my take on the OP. Lots of "managers bad"
| without recognising the faults of engineers in that
| process.
| sirwhinesalot wrote:
| I'm sorry to hear that, indeed, the engineers have to
| follow through on their end as well. That means "working"
| software, minimally functional, has to be delivered ASAP,
| at least to be able to gouge customer engagement.
|
| "Design Patterns" and the latest "Web Framework" fad are
| the opposite of delivering working software. How you find
| people with the right mentality? I'm not sure.
|
| Low-level game devs tend to have that "make it work"
| mentality but they like to reinvent the wheel a little
| too much because the existing wheel is 0.1% slower than
| their custom made one.
|
| Web devs are the opposite, they seem to think the wheel
| has manifested itself from the ether. They probably don't
| even know about half of the 50 wheels they brought into
| the project, and they'll replace them with newer, shinier
| wheels in a week.
|
| I think hiring a good team lead with the right priorities
| is key. Not a "manager", but the team member everyone
| else looks up to and follows out of their own volition.
| It might be worth wasting a lot of money and time on
| finding and hiring that person at the very beginning. If
| you do, the rest should fall into place, as they'll hire
| people who work well with them, meaning same priorities.
|
| Look at the impact someone like Jim Keller had on the
| companies he worked for, as an example.
| blowski wrote:
| Yep, both managers and contributors have a faulty model
| of agile. We're all guilty of it, even those of us who
| know it when we see it because we know the theory so
| well.
|
| Finding people with the right mentality is, as you say,
| very hard.
|
| The temptation of the manager is to get people with the
| wrong mentality and wrap them enough process that it will
| fix them. The temptation of the contributor is to blame
| the manager without looking at their own faults.
|
| As good a solution as I can suggest is to work with
| people who are willing to collaborate on a positive
| outcome, and go through genuine continuous improvement.
| sirwhinesalot wrote:
| And just to clarify, I've been both the "shinny new
| framework" and the "I can make it 0.1% more efficient"
| guy at different points in my admittedly short career
| (still a senior though). These days I'm the "make it
| work" guy but only after suffering the negative outcomes
| of the other two a little too much. You only really "get
| it" after doing the "wrong" way first.
|
| I've also had to deal with the "bad" manager that gives
| no push (nor any time) for stabilization, leading the
| code to a near-project-killing state of constant
| malfunction. Quite a few of the principles in the
| manifesto are about avoiding exactly this state, but they
| too are not followed correctly.
|
| The following are in a different order in the manifesto,
| but I think this should be the way to read them, they
| almost form a coherent paragraph:
|
| "Continuous attention to technical excellence and good
| design enhances agility. At regular intervals, the team
| reflects on how to become more effective, then tunes and
| adjusts its behavior accordingly. Agile processes promote
| sustainable development. The sponsors, developers, and
| users should be able to maintain a constant pace
| indefinitely."
|
| This means quality needs to be considered from the
| beginning and maintained, but that's not contradicting
| the fast delivery, quite the opposite (proven by many
| studies on Continuous Delivery).
|
| Quality arises from constant refactoring the working code
| to be better, based on the results obtained from seeing
| that code running. Not from planning ahead with some
| insane micro-service bullshit architecture 3 months in
| advance for a project that probably will never scale to a
| size that needs that nonsense (at which point you deal
| with it).
|
| But you _have_ to give time for that cleanup work, and
| introduce a culture that demands that quality (where
| quality is measured by the software working well and
| delivering value, not by how theoretically "clean" the
| code is) otherwise it simply won't happen.
|
| I've also had to deal with the "good" manager that tries
| to fix the above issues (after they happened) with
| processes. In my experience they just slow down velocity
| and don't resolve any of the actual problems. It's like
| telling a plumber that is almost swimming in shit to read
| and sign a 20 page document before turning off the valve
| of the pipe that's spewing brown liquid everywhere. That
| plumber is just going to hate you.
|
| The only thing that works is to demand both continuous
| delivery and consistent quality (and allow time for the
| latter at the expense of the former if need be), ensure
| you have the right lead, communicate openly and
| regularly, and then let the team do its thing. If the
| devs and PMs don't see each other as allies rather than
| annoyances, the whole thing falls apart.
|
| Also all it takes is 1 bad dev to spoil the bunch, I've
| seen them do so much damage it's nuts (stuff like
| introduce some whole new web framework nobody else in the
| team knows on some part of the project, or rework entire
| parts of the code to be async even though then it doesn't
| work with the rest of the codebase). Code review / pair
| programming is supposed to prevent this but if the team
| lead lacks the strength to keep devs like that in line,
| you're screwed anyway.
|
| "Individuals and interactions over processes and tools"
|
| If the individuals and interactions are wrong, no amount
| of processes and tools will fix it... I guess companies
| the size of Microsoft and Google can throw enough money
| at the problem that things work out somehow, despite the
| abysmal quality of most of their software.
| UK-AL wrote:
| Pretty well since he at VFX company he seems to working
| closely as a team and with his customers.
| [deleted]
| mkl95 wrote:
| > complaining about needing to do documentation, or basic
| project management?
|
| Some engineers are allergic to teamwork. I deal with coworkers
| with a similar attitude on a daily basis.
|
| The most frustrating aspect of it is that companies are usually
| bad at acknowledging someone is a bad fit for a project or a
| team, even when they are shown solid evidence.
|
| A big part of it has to do with how broken the interviewing
| process is - the focus at the moment is almost entirely on
| coding exercises and ignore tasks that many developers perceive
| as boring but can be crucial, such as writing documentation. It
| leads to mixed results where you end up hiring some engineers
| with T-shaped skills along with absolute code monkeys.
| shortformblog wrote:
| This guy also wrote a hater's take on open-source a few months
| back: https://liou28335.medium.com/why-i-dislike-open-source-
| acbc2...
|
| Something tells me he's gunning for that Medium paycheck.
| mschuster91 wrote:
| It's not like the points he is bringing up are invalid though
| - and I say that as someone who actually likes using,
| creating and contributing to FOSS projects. Most of them
| eventually boil down to funding - it's _rare_ that open
| source projects get decent funding or that big-co employees
| are allowed to feed back stuff back upstream. The result is a
| shit ton of people all doing what they want, but there is
| _no_ overall vision where the ship should head - and those
| that do want to break the cycle of misery often enough get
| badly burned. Just look at systemd, how much hate it got and
| how it 's practically unthinkable now for people to ship
| handcrafted initd scripts instead of a sane unit file?
|
| How many Heartbleed, left-pad or whatever similar instances
| of catastrophe does the IT industry need to recognize that
| relying on self-exploitation and intermittent government
| grants is not the way forward?
| deadbeeves wrote:
| That's true, the points are not invalid. Some of them
| aren't even coherent.
| op00to wrote:
| Oh man, that open source article is hilarious! Thank you for
| sharing.
| ljm wrote:
| I haven't contributed to open source in a few months and I
| still can't find a date to take to Starbucks. What am I
| doing wrong?
| politelemon wrote:
| > Medium paycheck.
|
| I'm sorry, what? Out of the loop here.
| shortformblog wrote:
| I'm referring to the Medium Partner Program, which pays
| based on level of engagement with readers, particularly
| subscribers (as this is a Medium post).
| ethbr0 wrote:
| Find "What Stats/Data Points Will Be Used to Calculate
| Medium Earnings?" in the link: https://medium.com/blogging-
| guide/how-much-money-can-you-mak...
|
| But basically: outrage increases readership increases
| Medium author payout
| andersonmvd wrote:
| Focusing on the author instead of the discussing the topic
| really misses the point imho. We don't get good discussions
| from it. The point is the amount of inefficiences in big corps
| and how people react to it. This post has so many upvotes for a
| reason.
| osigurdson wrote:
| 3 years, 20 people, 24K LOC does sound objectively inefficient
| to me for the project as described.
| ano88888 wrote:
| Yep. I think the author fails to understand that coding is only
| a small part of the process of writing production software.
| sdevonoes wrote:
| But there are different roles that come into play when it
| comes to writing production software:
|
| - the code, obviously
|
| - infrastructure
|
| - documentation
|
| - wireframes, mock ups
|
| - user manuals?
|
| - monitoring
|
| - ...
|
| Software engineers shouldn't be the ones who address all the
| points above (otherwise that leads to burned out developers
| like the author).
| rxhernandez wrote:
| Do you think that sw engineers at startups aren't largely
| writing code for most of their job?
| onion2k wrote:
| I think sw engineers at startups very often write way too
| much code rather than spending time thinking about, and
| talking about, what to write.
|
| As the old saying goes, "you can save hours of planning by
| doing weeks of coding."
| UK-AL wrote:
| Most discussions at large corporations are bikeshedding.
| Huge issues are ignored, but some minor detail which can
| be changed easily later gets talked about for weeks. It's
| often because its a detail middle management can
| understand, but the huge issue isn't.
|
| You then have to spend a significant amount of time
| trying to guide people to focus on the right things. And
| that is draining.
| dgb23 wrote:
| The delivery of the message is a rant. It's blunt and negative.
| But the content is something that many polite, loyal workers
| will tell you after a beer or two (so to speak).
|
| You are mentioning perspective and priorities. But from what I
| know these are exactly the problem. The more people you have
| that are disconnected from production and use, the more BS work
| tends to get generated. Not only because of increased
| bureaucracy and overhead, but also because decisions get made
| by disjointed actors and are often based on buzzwords or
| company politics.
| rob_c wrote:
| Unfortunately what you have just said is given as a shining
| example of why some coders hate other coders. If they're not
| going to contribute to core work, then add "perceived value"
| like docuemntation which a good manager should be allocating
| people to rather than wasting time in more meetings.
|
| There is no real excuse why when you're paid to code you're not
| doing that 4-5hours a day at least 5 days a week. Career
| development is one thing, but there are 7 working hours between
| 9-5 so if someone wanted to work on that they have a full
| 10-15hrs a week excluding a break for lunch. Lets take out 5hrs
| of meetings a week which is still likely too much to be
| productive and we're down to: ~10hr for personal growth, ~5hr
| for lunches, ~5hr of meetings to keep people up to date and
| 20hr of actual work every week out of every employee.
|
| Some meetings are important. Most are not. This is another
| common problem that middle-management gets into. Constant
| cracking of the whip and arguing-about/discussing small details
| is just toxic to productivity. (Small here being what
| style/color/toolkit. Not knocking up a prototype and pivoting
| when needed based on strategy and risk analysis performed at
| the start of a good project).
|
| Most "divergences" or decisions can be worked out through a
| SWAT analysis (yes I'm quoting Scilicon valley), or by managers
| making decisions and pissing someone off some of the time
| rather than holding everyone back all of the time.
|
| I've worked for managers with both management styles and I can
| guarantee the boss that makes a decision (even if it's wrong)
| is better than the boss that holds 5 meetings on the topic,
| because often you'll either get over it and move on, or prove
| it's wrong by the 2nd/3rd meeting and will still be ahead of
| the 5-meeting nod-fest.
|
| This mantra of hire more bad coders or letting talented coders
| go to waste because they're not being allowed to do their jobs
| is adding to a huge bubble in the sector and frankly, on the
| precipice of a major recession I think people in such companies
| should be starting to panic.
| sshine wrote:
| > complaining about needing to do documentation
|
| The article's formulation:
|
| > You will be asked to write a 50-page documentation for some
| little code you wrote.
|
| The author does not complain just about writing documentation,
| but about writing an unproportionate amount of it that
| presumably isn't being read by anyone. I've seen that happen.
| People writing essays about software that are bound to get
| outdated and will never be read by anyone. In systems that are
| disconnected from the source code.
|
| > The writing is smug and shows no self awareness
|
| Maybe I share the author's disdain for the corporate setting,
| but I don't see the smugness.
|
| While the article may not acknowledge the cost and value of
| doing things slowly and bureaucratically, I fail to see how
| that is an expression of lack of self-awareness. It is mainly
| an expression of a preference for seeing direct change to
| business logic in a short amount of time, even for aging
| projects, because of direct ownership.
| oneeyedpigeon wrote:
| I've never seen anyone having to write a 50-page document
| _just_ for "some little code", unless the author's
| definition of "some little code" is drastically different
| from mine. Without anything to back it up, that statement
| comes across as a huge exaggeration.
| mytailorisrich wrote:
| > _The author does not complain just about writing
| documentation, but about writing an unproportionate amount of
| it that presumably isn 't being read by anyone. I've seen
| that happen. People writing essays about software that are
| bound to get outdated and will never be read by anyone. In
| systems that are disconnected from the source code._
|
| This has been the norm more often than not in most companies,
| especially larger ones. Hence the Agile Manifesto, written by
| people who've been there again and again.
| watwut wrote:
| And still, working in company that does not document what
| the system does, it sux massively more.
|
| Because end result is that no one knows how to use our own
| software. You dont know what it is supposed to do, so it is
| impossible to keep that stuff working. It takes ridiculous
| amount of time to configure anything or reproduce bugs,
| because you need multiple calls to find the one person who
| barely remembers.
|
| Also agile manifesto is 20 years old. Agile is literally
| what most large dysfunctional companies do these days. It
| does not have no new solutions to actual real problems of
| companies, because it is old.
| mytailorisrich wrote:
| No-one ever suggested not to document!
|
| The comment I replied to says " _inappropriate amount_ of
| documentation ", the Agile Manifesto says "
| _comprehensive_ documentation ".
|
| That's the problem. Months, if not years, spent on pages
| after pages of comprehensive documentation that does not
| add any value and is obsolete by the time you start
| writing actual code.
|
| Lastly, the age of something is not a relevant criterion.
| Not much has actually changed over the last 20 years.
| What has changed is the explosion of web-related
| software, which is actually the best suited for the ideas
| behind the Agile Manifesto.
| watwut wrote:
| > That's the problem. Months, if not years, spent on
| pages after pages of comprehensive documentation that
| does not add any value and is obsolete by the time you
| start writing actual code.
|
| This picture is not any real company I _ever_ worked in
| or real company I heard of from friends. Literally, not
| even before agile manifesto.
|
| > Not much has actually changed over the last 20 years.
| What has changed is the explosion of web-related
| software, which is actually the best suited for ideas
| behind Agile.
|
| That is not actually true, really. A lot did changed.
| bbarnett wrote:
| This also glosses over something else. Comprehensive
| documentation can even be really well documented code!
|
| And in small corps, there's the "guy who wrote it" was
| "hit by a bus" scenario. It doesn't matter how dilligent,
| or how faithful someone may be when they leave, eg
| walking a replacement through the codebase can't happen
| of you're dead!
|
| This is how I document. I think about being hit by a bus,
| and what would this corp do? A replacement hiree do? See?
|
| Not doing this is, IMO, should be criminal. Like a CFO
| not keeping books.
| onion2k wrote:
| _People writing essays about software that are bound to get
| outdated and will never be read by anyone._
|
| I write a lot of documentation entirely with the awareness
| that no one else will read it. I write it for myself. I don't
| want to have to remember the intricacies of a system. I want
| to write things down, then move on immediately, and have the
| security of something I can refer back to if I need it when I
| revisit the system.
| turminal wrote:
| But doing so is your personal preference, you (i hope) are
| not required to do so. Some people find it easier to
| organize their work differently or not at all. Some people
| are astonishingly productive despite not writing anything
| down, ever.
| onion2k wrote:
| _But doing so is your personal preference, you (i hope)
| are not required to do so._
|
| I am required to in the sense that I define the policy
| about what gets documented on my team, and I said we
| write documentation about everything.
| LeanderK wrote:
| What if the teams changes? Intricacies must be documented
| despite that probably nobody will ever read it. Somebody
| might depend on it.
|
| Writing code is more about communicating how to solve a
| problem than just solving a problem, that's how I view
| it. If you don't communicate, nobody except you will ever
| understand it. It might be that you don't need to
| document a lot, maybe most is obvious if the key parts
| are sufficiently explained. But it's vital and sometimes
| it's better to write a bit more than a bit less. A thing
| is, outdated documentation might be worse than none, so
| it's a delicate balance.
| wruza wrote:
| _What if the teams changes?_
|
| Yeah, documentation will definitely help in this case.
| With it, you can swap teams and even companies, and it
| still works! This only fails in companies which do not
| review documentation and have no routine for keeping it
| in sync and testing it on e.g. newcomers, like you do for
| backups. Cause otherwise it is as good as never tested
| six months old backup.
| LeanderK wrote:
| It's always fun if a product is based on 20 year old code
| where there are parts that nobody can touch because
| there's nobody around who understands what's going on
| there. I once saw a flight-training software (I think it
| was for helicopters?) where the physics engine just
| didn't get touched because they don't know what's going
| on. Every change was essentially a hack around this blob
| of years old, highly optimised but totally
| incomprehensible C.
|
| EDIT: It might have even been fortran code. The rest of
| the project was C++
| onion2k wrote:
| _I once saw a flight-training software (I think it was
| for helicopters?) where the physics engine just didn 't
| get touched because they don't know what's going on._
|
| This is an interesting case, because it's something that
| I probably wouldn't document. Code should be readable. If
| you're writing down how your code works in a document
| then something is wrong with the code. Documentation
| can't fix an incomprehensible codebase. I document how
| algorithms work, what the business logic is for things
| (which is another algorithm really), how applications
| work in a 'data flow' sense, what integrations there are
| with external services and how they work, what things
| _mean_ , and so on.
| native_samples wrote:
| Normally working out how a complex piece of software
| works from only the source code is called reverse
| engineering.
|
| I've encountered this "readable code means I don't have
| to document" idea before. I have no time for it, it's
| just wrong:
|
| 1. Important things aren't easily visible in the code,
| most commonly _why_ the code does a particular thing.
| "Readable" code, which is a very subjective standard, can
| only tell you _what_ it does but not the underlying
| rationale.
|
| 2. Writing docs often exposes the fact that the way the
| code works, or is expected to be used, doesn't make sense
| or is sub-optimal. If your docs include lots of caveats
| or explanations of nonsensical behaviour then it's a good
| hint you should go back and think again.
|
| 3. Figuring out stuff by reading the code is often
| drastically slower than reading the docs. That's why all
| professional APIs have good docs and people grumble and
| moan when expected to use code that doesn't.
|
| 4. The sort of people who argue this, in my experience,
| often don't actually write readable code, they just tell
| themselves they do.
| sshine wrote:
| This type of documentation is the only kind I have positive
| experience writing. Tutorial-like documentation is another
| kind I have positive experience reading.
| jp0d wrote:
| Everyone is at a different stage in their lives. It feels like
| the author hasn't had much challenges and found most of the
| work boring. I agree with some of the points the author has
| raised but not all. I don't agree with your comment about
| "writing is smug and shows no self awareness". It feels like
| you're jumping to a conclusion.
| scotty79 wrote:
| Working directly for clients and being personally responsible
| for the entirety of the development process gives you this
| perspective. You can have successful multi-person projects with
| almost no documentation and project management contained
| entirely in a single trello board with basic features.
|
| Then, when you land in a corporation you can see how large
| teams barely manage to match your former personal productivity
| by choosing wrong technologies, taking wrong approaches,
| discussing irrelevant things in countless meetings and
| producing tons of write-only never-read documentation that gets
| obsoleted almost as fast as it is written. If you are too
| youthful and idealistic you can get a little arrogant
| experiencing this inefficiencies when you have a context to
| fully appreciate their insanity.
|
| Or you may take another approach. That efficiency actually
| doesn't matter. People don't work to achieve anything. They
| work to get paid. And corporations have a lot of money. So the
| game is no longer about building stuff efficiently. It's about
| raking in as much money as you can for as long as you can and
| every inefficiency that justifies further work is actually best
| friend of everybody involved.
| mrcartmeneses wrote:
| " So the game is no longer about building stuff efficiently.
| It's about raking in as much money as you can for as long as
| you can and every inefficiency that justifies further work is
| actually best friend of everybody involved."
|
| You're describing the goals of the individual becoming
| divergent from the goals of the company.
|
| In the article the writer described his team's goals at the
| VFX software company as being well aligned with the goals of
| the company and the customers. They even stayed late because
| they were enjoying solving the problem so much.
|
| The same misalignment in goals is what made Communist Russia
| so awful. The stated goals were about providing prosperity to
| all workers and citizens of the USSR, but the goals of the
| committees became about personal advancement and the
| preservation of the party. It could be argued that the
| extreme job security of the dictatorship allowed this
| situation. If there had been a way to democratically fire
| officials, they would have been more aligned with the goals
| of the people. (A politician is only as good as your ability
| to fire them.)
|
| Many large companies end up like the USSR. The way to solve
| this is to allow teams to fire their managers.
| gitfan86 wrote:
| "The way to solve this is to allow teams to fire their
| managers."
|
| I don't follow. Wouldn't most teams replace their manager
| with a manager who would give everyone the biggest raises
| and the easiest working conditions?
|
| Why would a team want a manager who cares about the goals
| of the company?
| hutzlibu wrote:
| "Why would a team want a manager who cares about the
| goals of the company?"
|
| Bind their avaiable budget to their success.
| _notathrowaway wrote:
| Well, there is that, but you know, the countless murdering
| of their own people did not help either.
| [deleted]
| gitfan86 wrote:
| "That efficiency actually doesn't matter. People don't work
| to achieve anything. They work to get paid."
|
| That is fine, but now you are stuck playing politics. You
| have to keep whoever is in charge of the money happy. And no
| value is created because everyone is trying to avoid getting
| blamed for problems.
|
| Obviously, real companies, making real software also have to
| keep customers happy, but at least those requirements are
| somewhat predictable as they are tied to the real world use
| case, and real world value customers are getting from the
| product.
| ethbr0 wrote:
| Author is every software engineer I hate to work with. One who
| thinks that code is the only truly important part of a project.
| It's not.
|
| "Delivering a product that solves end user needs and is as
| maintainable and reliable as possible" is the only truly
| important thing, and only some of that is code.
|
| Meetings generally aren't for developers. They're to keep
| everyone else involved with the project sync'd up.
|
| Do I and every software engineer wish we had fewer meetings?
| Absolutely. Do I recognize that meetings are valuable to
| _people not me_ and are critical in helping them deliver their
| (often non-code) parts of the project? Absolutely.
|
| Not recognizing that after 20 years in the industry is
| baffling.
|
| I'd be curious if author has ever worked on a large, 1 year+
| project that went awry because the requirements were incomplete
| and the end users' needs poorly understood. If so, then I'm not
| sure they took the right introspective lessons away from that.
|
| _Edit:_ And I recognize that some companies are incapable of
| delivering software, due to broken development processes. I 've
| worked for health insurance companies and know how baroque it
| can get. But that's been the exception rather than the rule.
| Jensson wrote:
| > Meetings generally aren't for developers. They're to keep
| everyone else involved with the project sync'd up.
|
| But if every project has non-developers deeply involved in
| them then the software is very shallow. So to me anyone who
| thinks that every developer needs to be involved in such
| meetings just shows they have never worked on anything deeper
| than a crud app with some basic business logic. If you work
| on anything like a compiler, a garbage collector, a database
| engine, a load balancer, any kind of software framework etc
| then you will have plenty of teams never needing to talk to
| non-developers.
| ethbr0 wrote:
| > _If you work on anything like a compiler, a garbage
| collector, a database engine, a load balancer, any kind of
| software framework etc then you will have plenty of teams
| never needing to talk to non-developers._
|
| Replace non-developers with "people outside your immediate
| team". In a developers-all-the-way-down shop, there are
| still people who are intricately dependant-on but not
| involved-in your work.
| Jensson wrote:
| But developers are much better at describing what they
| need so there is much less need for meetings in those
| scenarios, instead they just send emails or open bug
| reports that gets resolved without the meetings.
| ethbr0 wrote:
| Generally, I'd agree, but I've also worked with
| developers who are as egotistical, shortsighted, and/or
| stupid as the worst person with any other title.
|
| Being a logical, cooperative, well-communicating human
| being is not a requirement to be a developer.
| Jensson wrote:
| > Being a logical, cooperative, well-communicating human
| being is not a requirement to be a developer.
|
| If your company is fine with them being unable to
| communicate then your company obviously is fine with you
| not being able to communicate as well, so why try? And if
| your company hires people who are good at communicating
| then there is little need for meetings between developers
| except politics, and most developers shouldn't have to
| deal directly with company politics.
| xpe wrote:
| > Not recognizing that after 20 years in the industry is
| baffling.
|
| Baffing, cognitively?
|
| Or is this a value judgment?
|
| Have you observed human nature particularly in the last ten
| years w.r.t. echo chambers?
| watwut wrote:
| To be honest, pretty much all the experienced developers I
| met understood that. The "my silo and nothing else" kind of
| thinking tends to be something unexperienced people are
| more prone to.
| capitalsigma wrote:
| "Consensus about any topic is impossible because political
| speech has become more polarized"
| xpe wrote:
| Yes -and- it isn't just political speech. Many developers
| naturally feel more comfortable with certain information
| sources (forums, blog posts, people, etc) and form self-
| reinforcing tribes around e.g. programming styles,
| languages, habits, editors, processes, and so on.
| Cthulhu_ wrote:
| I mean the author mentions meetings about the color of a
| chart... it's the kind of meeting they should be able to
| reject, because I don't believe they would have much of an
| opinion on the matter, only a decision that they can
| implement.
|
| So if you're in a position like that, assert yourself and
| your presence in meetings; do you have valuable input that
| they need? Is there a time set, a concrete goal / agenda? If
| you don't have to be there for any other reason but to be
| kept in the loop, can they just send a tl;dr?
|
| I mean I get that a lot of things need to be discussed - and
| a subject like chart colors can be reused for years after the
| decision was made - but not everything should be an all hands
| meeting. Have the least amount of people in a meeting to come
| to a decision and keep others in the loop. Let everyone do
| what they do best.
| varjag wrote:
| Rejecting meetings comes at a cost.
| vsareto wrote:
| I would argue most meetings can be mostly replaced with
| ticket comments, documentation, emails, and chats. Devs are
| constantly expected to adapt and learn new things, while
| others apparently don't need to learn to use comments,
| documentation, emails, and chats to stay informed.
|
| Learning to use search features should be a good step as
| well. Outlook has search, Azure DevOps has search, there's
| Google, and most chat programs have search as well. Some
| developers need to learn to use these too.
|
| You don't have to be a wizard at search engine flags or
| features or anything - it just needs to be the first thing
| you do to avoid shallow, easy-to-answer questions.
| koolba wrote:
| > I would argue most meetings can be mostly replaced with
| ticket comments, documentation, emails, and chats.
|
| s/would/should/
|
| The real benefit of those forms of communication is that
| you have a written, hopefully searchable, record of the
| discussion. It also forces people to mold their incoherent
| thoughts into complete sentences.
|
| Meetings should be reserved for brainstorming and decision
| making.
| UncleMeat wrote:
| My experience is the following:
|
| Many meetings can indeed be emails. Developers tend to be
| only so-so at identifying which meetings these actually
| are. And developers are _terrible_ at identifying which two
| week long email threads could have been a short meeting.
|
| It isn't enough to say "there are too many meetings" and be
| done with it. You need to identify which meetings can be
| removed - and that can be tricky.
| ryandrake wrote:
| Yes! My reply to "this meeting could have been an E-mail"
| is often: "OK, do you read your E-mail and respond
| promptly?" I love killing productivity-draining meetings
| and turning them asynchronous --BUT-- these meetings
| often get called because a decision needs to be made
| synchronously(now), and the decision makers can't wait
| two weeks while you get around to reading your E-mail and
| remembering to answer.
|
| Those meetings that are simply "status story time" where
| someone reads a doc to the room? Yea, they should be
| removed. I don't think anyone likes them.
| paganel wrote:
| Excellent comment, just wanted to add to this:
|
| > Delivering a product that solves end user needs and is as
| maintainable and reliable as possible" is the only truly
| important thing, and only some of that is code.
|
| that it should also bring money, or enough money, to be more
| precise.
|
| It may sound strange but lots of products that fall on your
| very on-point definition fail to bring enough money in order
| to keep the lights on (and then some), this is a point that
| gets lost on many software developers. For context, I've been
| a paid programmer for 15+ years now, mostly in small
| companies, maybe as part of bigger companies/projects the
| view is a little different and "bringing in money" is not
| seen as that important for the developers.
| 2143 wrote:
| [Tangent]
|
| > And this isn't to say that some companies aren't
| pathologically incapable of delivering software...
|
| "isn't", "aren't", "incapable"
|
| Three back-to-back negatives have me confused. Somewhat
| mysteriously, I (think I) understand what it means when I
| read it quickly, but if I pause to think I get confused.
| English isn't my first language :)
|
| Update: Thanks for editing to make it clearer!
| [deleted]
| ethbr0 wrote:
| Point. Edited and hopefully clearer. I try to keep non-
| first language readers in mind, but vernacular crept in
| before a second cup of coffee.
|
| IMHO, "this isn't to say" is a common expression in
| English, so I didn't register it as a negative. But you're
| absolutely correct.
| unlikelymordant wrote:
| Negatives cancel, so I think you cancel the first 2 and get
| "this is to say that some companies are pathologically
| incapable of delivering software", which reads a bit nicer
| 2143 wrote:
| Generally that works but sometimes it doesn't.
|
| For example, some people say statements like "I don't
| want no towels".
|
| What they really meant: "I don't want towels"
|
| What I get if I cancel the negatives: "I do want towels"
|
| The meaning flipped :)
| OJFord wrote:
| That is incorrect usage though; every rule 'generally
| works but sometimes doesn't' if we account for people not
| observing it.
| oneeyedpigeon wrote:
| But pointing out that language rules aren't something
| that people strictly adhere to, with rigorous logic, is a
| useful observation.
| OJFord wrote:
| Undoubtedly, but it was a response to someone explaining
| how to use English (correctly), not how to understand
| someone else using English (possibly incorrectly).
|
| If I say 'proper nouns have a capital first letter' I
| don't think 'actually oliver sometimes people don't do
| that' is helpful.
| pcthrowaway wrote:
| > That is incorrect usage though
|
| We don't need no education
| OJFord wrote:
| You wouldn't be here quoting that line if it were
| correct.
| ethbr0 wrote:
| Double-negatives in the "not+no" formulation tend to be a
| special case. The easiest rule (as you realized) would be
| "If there's a 'no' before the noun (direct object?), in
| an already negated phrase, then ignore the 'no'".
|
| It's technically incorrect but common English.
| lelanthran wrote:
| > "Delivering a product that solves end user needs and is as
| maintainable and reliable as possible" is the only truly
| important thing
|
| I gotta disagree: "Delivering a product that solves end user
| needs and is as maintainable and reliable as _necessary_ " is
| the goal.
|
| Getting five 9s uptime on something that needs only 99%
| uptime is pointless.
| rob_c wrote:
| Was he hired as a product liaison with corporate to attend
| meetings with clients. No. He was likely hired as a
| developer. Most of this should appear as requirements via his
| inbox not be meetings he attends unless there is a screaming
| problem with a request.
| lupire wrote:
| Sure, if he is a junior engineer with the proverbial "20x 1
| year of experience" and is paid like one.
| ethbr0 wrote:
| I've worked at a fair number of companies (as either
| consultant or employee) and rarely have requirements landed
| neatly and fully-formed in my inbox.
|
| I'm sure it happens reliably somewhere, but I'd hazard not
| at most companies.
| rob_c wrote:
| That doesn't mean it doesn't happen when working with
| competent people doing their job well.
|
| Consultants only seem to get called in after things have
| gone wrong too so does your experience support that not
| doing this is bad practice?
| ethbr0 wrote:
| Agreed on consultants. It provided so much enlightenment
| on the multitudinous ways many companies can screw up the
| discovery and development process.
|
| Setting aside the "This company was fundamentally
| disfunctional" cases, my takeaway has been that knowledge
| gaps between roles are an underappreciated cause of bad
| development outcomes.
|
| Writing requirements is hard. Writing requirements
| without some intuition of what developers need to know is
| harder. Writing requirements without context on the
| business domain is harder.
|
| So the ideal BA is someone who is a developer who is also
| experienced in the business domain.
|
| The majority of companies don't want to pay enough to
| hire BAs with that experience.
|
| So you get users (who may know nothing about software) +
| minimum cost BA (who is doing their best, but has no
| context for anything) coming up with requirements, which
| are of course incomplete and/or incorrect.
|
| But fundamentally this problem is too large of a
| skill/knowledge gap between the user and BA, and between
| the BA and the developer.
| jseban wrote:
| Yeah but you get tired of the fact that all of the low level
| business people abuse their "rank" to turn you into their
| personal assistant.
|
| If I have to help them with everything, why don't I just talk
| to the users directly and write the requirements myself? It
| would be faster, and can even save the paperwork. This is
| modus operandi for contractors.
|
| Why do I have to drag along these type of bozos all the time,
| and suck up to them like they are my masters. Cut the fat and
| get rid of the useless bureaucrats. Or at least get rid of
| this stupid "rank" that programmers are "the bottom of the
| food chain" so they can at least root out the shitty PMs.
|
| Nobody complained when Steve Jobs delivered much more sharp-
| tongued rants than this article.
| dahart wrote:
| You should talk to users directly and write requirements
| yourself! And then teach the business people what you
| learned.
|
| > Nobody complained when Steve Jobs delivered much more
| sharp-tongued rants than this article.
|
| What are you referring to? Jobs alienated people all the
| time, people quit their jobs over things he said.
| danielvaughn wrote:
| A few days ago, I made a comment about good developers
| knowing how to think of their work from the business's
| perspective. One guy responded by saying his only job is to
| write code and he doesn't care about anything else. I just
| can't imagine coming to that perspective, even if I
| understand the desire to have minimal responsibility.
| matwood wrote:
| > One guy responded by saying his only job is to write code
| and he doesn't care about anything else.
|
| Which is such a weird perspective to me. The point of
| writing software for business is to solve a business
| problem. Maybe it's a function of working in small
| companies and/or roles that straddle code writing and
| business, but I have a hard time writing good code unless I
| know the business problem space.
|
| It's also why I think I don't get too worked up in the
| language arguments. I've written code from VB5 to Java to
| Go to JS all which deliver immense business value. When I
| think about the best code I've ever written, I don't think
| about how pretty it was or even the language, but is it
| still in use 5-10-20 years later.
| xpe wrote:
| Code 'longevity' is influenced by many more factors than
| code quality; e.g. rate of business change, traffic
| changes, infrastructure dependencies, and the complexity
| of the surrounding system.
|
| As a pathological counter example think about arcane
| obtuse code that people are afraid to modify.
| matwood wrote:
| That's a good point. I didn't really define what I meant
| by 'best'. In some cases the code was used, updated,
| etc... for many many years by people I knew. If people
| were too afraid to touch it when a bug was found, then
| definitely not good. But, if people had no need to touch
| it b/c it works, that's a good spot to be also.
| oneeyedpigeon wrote:
| I think it's a failure to separate work and hobby. A lot of
| -- heck, maybe even most -- developers get into it because
| they enjoy programming. That's entirely reasonable, but you
| have to accept that _some_ compromise is going to be
| required of you in the working world. You can 't just do
| whatever you want to because it's fun and get paid for it.
|
| If you find yourself empathising with the author, you
| really only have two choices:
|
| a) Quit, do something else for a living, enjoy your
| programming in your spare time
|
| b) Suck it up
|
| Even rock stars have to sit in meetings and do things
| they'd rather not, like hold press conferences, give
| interviews, etc.
| zip1234 wrote:
| At many big companies there is plenty of room for those
| types of people. They just need to be put in a role where
| their customer is another developer. They can see things
| from the developer perspective and can be plenty successful
| working on things that are not public facing.
| UK-AL wrote:
| These are often some highest paying and prestigious jobs
| in large companies.
| bayindirh wrote:
| As a developer (and sysadmin), I want to write less and less
| code as time passes. It's not I don't enjoy coding, on the
| contrary.
|
| However, I understand that a project is documentation and
| future planning, too. So, I want to build an artifact
| complete with its documentation, which can be sustainably
| moved forward by anyone other than me.
|
| If I don't document what I've coded, then the joy project
| becomes a weight on me, and prevents me from moving to new,
| bigger things. Also, I can show the whole shebang as "I made
| dis!", and anybody can have an idea what the project is all
| about.
| brabel wrote:
| As a developer, I've been writing lots and lots of code
| every day for around 15 years. I write documentation quite
| rarely, only when it's a customer facing feature (a lot of
| stuff that I do is in the background where customers have
| no idea things are happening) or a very technical piece of
| code that I want future developers to understand better and
| keep the intended design in mind when making changes (this
| is much more common for me to do). Most documentation,
| however, can easily get stale almost as soon as it's been
| written, so with experience, you learn to focus on the
| important concepts as opposed to implementation details..
|
| I rarely have meetings about things are not entirely
| technical, and I actually enjoy the meetings we have as we
| always come up with valid points that one alone may not
| have considered.
|
| Anyway, just wanted to mention my experience as I don't
| agree that as you become more experienced, you tend to
| write less code. I am as productive now as I've ever been,
| even being one of the main and most experienced developers
| in a team of 20+.
| bayindirh wrote:
| Ah, no, I didn't mean to share my perspective as "this is
| the correct way, yo shall do as me". It's just my
| perspective and formed by my own experience and work
| structure.
|
| As it comes up here from time to time, I work as a
| sysadmin, and have my side academic gig, which I'm the
| solo developer on a serious piece of code. I design,
| code, test and verify the whole thing, which is immensely
| satisfying.
|
| My daily job is very connected to my academic gig, and
| they feed each other. As a result, I can apply what I've
| learnt from one to the other. We're a small team, doing a
| lot of big things, hence my work environment is
| drastically different than yours.
|
| The gist of my comment was actually, "As I get more
| experienced, I design and write less code because it's
| _more correct_ from get go. Then I document it at the
| level needed and I have something concrete and which can
| be passed over to anyone who wants to maintain or fork
| it, and this is equally, if not more satisfying ".
| urthor wrote:
| The thing is, there is absolutely a cost for all those
| meetings. Time spent working with stakeholders and building
| consensus takes away from the urgency and energy you can
| devote to good work.
|
| My experience is very similar to the article's. I just draw a
| very different set of conclusions.
|
| For risk averse, cost constrained, low stakes projects.
|
| Good engineering work is neither demanded or required..
|
| My viewpoint is simple.
|
| Don't work on software nobody cares about.
|
| Work on software that's doing something genuinely important.
|
| Then people will feel obliged to cut the meetings short and
| be more efficient.
| tremon wrote:
| _Time spent working with stakeholders and building
| consensus takes away from the urgency and energy you can
| devote to good work_
|
| I don't see how I should square that statement with your
| next:
|
| _Don 't work on software nobody cares about_
|
| How do you know what software people care about unless you
| spend time working with the stakeholders?
| amitport wrote:
| I would even add that sometimes "maintainable and reliable"
| are overrated.
|
| Sometimes being quick to market is more important then having
| to maintain the product. Sometimes providing a bad product is
| only relative to the competition (which may have a worse
| product). Sometimes having a good customer service is more
| important than the reliability of the product. etc.,.
|
| I do agree with solving the end user needs... if a client
| does not need your product you really can't run a company for
| long.
| slumber86 wrote:
| >Sometimes providing a bad product is only relative to the
| competition (which may have a worse product).
|
| Eventually will came someone with a truly good product and
| distrupt the market
| amitport wrote:
| will they?
|
| In some fields having a good business and regulatory
| relationship with the customers (e.g., hospitals, DoD,
| banks, etc.,) is much tougher than building the product.
| There are many barriers in place and these fields are not
| so easily disrupted (having a superior product is
| definitely not enough).
|
| Also note that having a bad product now that is better
| than the competition does not mean you cease to improve.
| blowski wrote:
| Exactly. I've worked in companies dominating a particular
| niche. Everything about the technology is "terrible" from
| an engineer's perspective, and yet nothing shifts their
| dominance. A massive rewrite that damages customer
| relationships is more risky than doing nothing to improve
| it.
| croes wrote:
| Or this company is bought up, which was there first and
| therefore has the larger financial reserves.
| Joel_Mckay wrote:
| >"maintainable and reliable" are overrated
|
| That is popular opinion among the unemployed, as hoisting
| that BS on your project lead has real world consequences
| after your code audit. =)
| mattmanser wrote:
| It was Facebook's philosophy and also Twitter used to go
| down a lot in the early days. So I'm not sure I'd agree
| with your statement. It depends on your company culture.
| Joel_Mckay wrote:
| In general, a well planned API allowed Facebook to
| integrate a lot of 3rd party features to attract more
| users. Simply put, a messy standard is still a standard.
| ethbr0 wrote:
| Both are in a strong first mover / network effect
| industry (social). It's definitely an optimization in
| certain cases.
| amitport wrote:
| Here is a quick CEO dilemma: You have startup with about
| 4 people, you did a quick prototype, showed it to some
| potential customers and the worse has happened:
|
| They want it! and they want it now!
|
| The head engineer says it's all just a temp hack, it is
| completely shitty, they could give it to costumers but
| then the maintenance will be impossible, they will need
| months to add any new features on top of it, they will
| probably waste all their time on fixing bugs, and they'll
| quit if they have to maintain it for long.
|
| What would you do? (A) continue develop until you have a
| nice maintainable product, or (B) sell the product now
| and face the consequence of wasted developer time and
| loss of their motivation.
|
| Sometimes in such situations the answer is (A), but not
| always. It depends. How much money you got? how certain
| are you of the timeline for "finishing" the product
| properly? which option is riskier? How much competition
| you have and how likely they are to publish a product
| before you? What could having a real customer teach you
| about your product? What do you need in order to get the
| next round of investment?
|
| This is just an example, but IMO product graveyard is
| filled with great maintainable and reliable code no one
| had a chance to use. I love software and I'm really not
| disregarding its importance, I just think it's not always
| _the most_ important thing.
| Joel_Mckay wrote:
| A CEO rarely accepts designing a product for a single
| customer. If you did, than your team just becomes
| dependent contractor labor rather than a business.
|
| I will tell you a terrible secret of successful software
| companies: "One doesn't make money writing software, but
| rather reselling the same software mullions of times
| over."
|
| You should know this already. =P
| xpe wrote:
| > You should know this already. =P
|
| Groan. This comment could make its point without assuming
| what the other party knows or doesn't.
| amitport wrote:
| You seem to talk in absolutes while I'm just
| acknowledging there is more than one right answer.
|
| And I do have specific real cases from my experience in
| mind... One of a great product that never finished (money
| ran out, CEO didn't want to provide something that was
| for "a single customer" as in your words), another of a
| shitty buggy unmaintainable software that did grow a
| company from 4 to 100 employees then to an exit and only
| then came the nice eased-back rewrite.
| Joel_Mckay wrote:
| The 3 year survival odds are about 1:23 for
| software/services startups, and 1:70 for hardware
| projects.
|
| I have culled many half-arsed options... and the
| decisions are far from arbitrary. Also, who budgets for a
| project burning over $100k a month in labor without a
| detailed plan... lol
| amitport wrote:
| I agree with what you wrote here... I just don't see how
| it relates to what I said.
|
| Start-up have terrible survival odds. Decisions should
| not be arbitrary. There should be a detailed plan.
| xpe wrote:
| That moment when one person recognizes what is happening
| in a conversation; namely;
|
| 1. when two people are "talking past" each other.
|
| 2. It isn't only about 'what I'm saying'; multiple
| streams of conversation can happen at the same time and
| all be useful and even true
| xpe wrote:
| Yes, I agree, there is a continuum there. It is easy to
| judge from afar, but it is much more insightful to see
| what people do in real situations with real resource
| constraints and complicated human beings trying to
| succeed -- and not always with the same definitions of
| success.
|
| For example, for many engineers, what they (a) can learn
| and (b) be proud of while building a product is a big
| part of success.
|
| For some CEOs, engineer satisfaction is only a secondary
| or tertiary goal -- their business success crowds out
| most other things. This is complex; sometimes this drive
| is what helps a business succeed; sometimes this is why
| people get treated poorly or ethics go out the window.
| Joel_Mckay wrote:
| "what people do in real situations with real resource
| constraints"
|
| As this is mostly on-topic for the parent thread... I can
| respond...
|
| When faced with a painful product launch/schedule, as
| management messed up resource budgets etc... there are a
| few actions one can usually take:
|
| 1. ignore the issue, accept a 60% probability of failure
| risk, and naively hope management is replaced
|
| 2. adjust current project scope, follow MVP rules, and
| defer features for v2
|
| 3. cull the project, and eject unprofitable/unhelpful
| members from the team
|
| 4. Leave the company before the shite hits the fan
|
| Note, compromising workmanship is not on the list, as a
| business "Brand" is often more important than non-
| stakeholder opinions of intangible asset valuation.
| xpe wrote:
| > Author is every software engineer I hate to work with.
|
| Wow. This looks like a quick and harsh over-generalization.
| This sounds like a pretty deep-seated lack of understanding.
| xpe wrote:
| How we write here on HN is important. Write once with
| overgeneralizations, and then N >> 1 (many more than one
| person) have to read that sloppy thinking. It is lazy
| writing/thinking and, in effect, disrespects our collective
| experience.
| xpe wrote:
| It is easy to confuse "so little perspective" with "a different
| set of values". This seems to be the case with ^.
| Simon_O_Rourke wrote:
| > The writing is smug and shows no self awareness
|
| Definitely. This style of writing immediately put me off the
| rest of the piece. I've worked with software engineers like
| this, and it's no fun.
| reacharavindh wrote:
| The more years I have spent in my career, I have come to
| realise that coding and implementation of something is NOT the
| only productive part of the project. Even though I like to roll
| up my sleeves and "just get it done already", I have matured to
| understand that (1) scoping a problem correctly and aligning it
| to a function of the product, (2) documenting the need and its
| integration with other parts of the project/company are much
| harder and more important actions that makes sure that you're
| implementing the right thing and not wasting/overengineering
| the feature.
|
| It takes a bit more perspective to understand that no one can
| know it all or do it all. Contributors other than "coders" and
| implementors such as Product owner, scrum master, tester,
| manager play a key role in guiding the implementation. By the
| nature of those jobs, they are not as quantitatively measurable
| as an engineer's job.
| xpe wrote:
| ^ wrote:
|
| > but complaining about needing to do documentation
|
| Here is what the blog post writes:
|
| > You will be asked to write a 50-page documentation for some
| little code you wrote.
|
| The parent post (^) misread and mischaracterized the blog post.
| It is notable that the ^ called the other author 'smug' and
| then proceeded to respond to the least charitable
| interpretation.
| mschuster91 wrote:
| > but complaining about needing to do documentation, or basic
| project management
|
| There's a difference between "writing documentation that fits
| the need at the moment" or "write fifty thousand pages of
| documentation no one will _ever_ read, just to check a checkbox
| on some manager 's checklist / compliance requirement". Or
| endless "sync" meetings that are effectively nothing more than
| filling the desire of managers to (micro-)manage.
|
| With a decade of industry experience from freelancing over
| small agencies to big-corp/government jobs I've worked, I can
| say this: The core problem at the root of most big-
| co/government projects and associated disasters is that there
| are way too many levels of "deciders" and especially a
| fundamental lack of trust in people to do the right thing. When
| everyone is just in cover-your-ass mode and no one is willing
| to risk making a decision that is not backed by weeks worth of
| analytics and big data, shit will hit the fan real hard sooner
| or later.
|
| The most successful projects are done by startups or in the
| big-co world where a significantly high-up person says "we're
| going to deliver a solution to the problem X" and everyone is
| focused on reaching that holistic (!) milestone, not on micro-
| optimizing their KPIs, OKRs or other bullshit. The key to
| success is trust, the focus on one shared goal and actually
| paying enough to hire decent seniors to lead.
| ljm wrote:
| I think if you read the author's other posts, they appear to
| just enjoy ranting. I wouldn't be surprised if they manifested
| after a beer or two considering how myopic and exaggerated they
| become.
|
| Alongside this we also have: open source is inferior because
| of... reasons, something about older developers ageing like
| fine wine unless they work as web developers with all of those
| young whippersnappers learning new JS frameworks every month,
| something else about maths and algorithms but is really about
| Big O Notation being bullshit.
|
| Not to dismiss the author's point: I'd like to believe they're
| being genuine and not just being controversial for clicks. But
| they have quite the chip on their shoulder it seems.
|
| Also, it is quite amusing. I do enjoy the occasional rant.
| mjburgess wrote:
| The issue the author is talking about, in my view, is caused by
| the natural lifespan of corps tending towards bloating middle-
| management. (Very hard process to fight).
|
| At the start the founder group are rutheless productivity-
| chasers. Then the corp expands to include the its-just-a-job
| group. Everything ticks along well, and at some point, the
| rutheless can't manage the group. So they hire _followers_ to
| listen to _their orders_ and thereby _manage others_. In this
| sense middle management is really "corporate following".
|
| Now you have the its-just-ajobs, rutheless-productives,
| rutheless-leaders, and leader-followers.
|
| When the corp grows too far the balance in these populations is
| thrown way off (by, often, the shortsightedness of the _real_
| leadership in balloning middle-management to cover for them).
|
| At this point all the meaningful decisions are still held by the
| exec, but middle management are now so large they have to "find
| something useful to do", which is regulate all the meaningless
| decisions.
|
| At this point most of the ruthelessly-productive leave, and
| you're left with the justajobs, leader-followers and the few
| clueless productives who'll destroy their mental health trying to
| grapple with it all.
| milkshakes wrote:
| this is the gervais principle
| mjburgess wrote:
| Same phenomenon, slightly different analysis.
|
| The gervais-style analysis mystifies some of the issues it
| describes. The heart of the group dynamics is "leader vs
| follower", "rutheless vs clueless" and "transactional vs
| passionate".
|
| A startup is largely "passionate rutheless leaders", it grows
| to include "transactional ruthless followers" (its-just-
| ajob), then to "passionate clueless followers" (middle-
| management). At this phase its highly stable... you hire in
| "passionate rutheless followers" (ie., more actual
| workers)... who also need more middle-management... and at
| somepoint this becomes unbalanced due to poor executive
| incentives.
|
| That gives you your large population of "passionate clueless
| followers" (ie., middle-management), and the death of the
| productive phase of corp. action, into a more rent-seeking
| (or death) phase.
|
| In gervais, "losers become sociopaths" in a mystifying way;
| and likewise the "clueless" population is inexplicably
| unpromotable. My breakdown, for example, clarifies why: the
| "clueless" population never become rutheless-leadrs as they
| arent leaders at all. They're followers.
|
| I think muddling "transactional" dispositions with
| "rutheless" ones also mystifies the issue, under gervais, the
| "noble sociopath" is hard to explain. Really, its that
| they're both passionate (internally motivated) and rutheless.
|
| ---
|
| NB., rough definitions: "leader vs follower" (I command vs. I
| am commanded), "rutheless vs clueless" (success requires it
| vs. virtue requires it) and "transactional vs passionate"
| (external-reward vs. intrinstic-reward).
| neutronicus wrote:
| "Passionate ruthless leaders" also aren't guaranteed to
| stay that way as the company gets more established.
| thawaya3113 wrote:
| I suspect a lot of this is survivorship bias.
|
| I suspect if one were to compare a large number of startups to
| one large company (or even better a portfolio of large
| companies), the "ruthless founders" will significantly
| underperform the middle management in large companies even
| after adjusting for the inherent advantages large companies
| have.
|
| The only reason the "ruthless founders" look better is because
| we usually only talk about the successful ones because
| unsuccessful ones have disappeared.
|
| Middle management is more successful and ruthless founders are
| less successful than immediate appearances would suggest.
| mjburgess wrote:
| sure, it's about ratios
|
| a business needs an executive, and at scale, it needs middle
| management to implement the general strategic direction set
| by the executive
|
| if there are more middle-managers than this requires, they
| start trying to own non-strategic issues -- which is where
| you get large numbers of meetings about non-issues
| ineedasername wrote:
| > _if we should display certain data using a particular chart_
|
| Why are software devs bothering with that to begin with? It seems
| like it should be something the user decides, even if they say
| something like, "I want a sparkline chart but make it real big
| and applied to all the data". And then I silently think to myself
| "oh so you want a regular chart but you heard the word
| _sparkline_ once but don 't know what it means. Okay, will do."
|
| edit: to be honest my users are reasonable and that sort of
| example is rare.
| stosto88 wrote:
| commandlinefan wrote:
| All software sucks because deadline >>>
| functionality/usablity/accuracy. No matter how hard management
| insists that this isn't the case. In fact, the more they insist
| that it isn't the case, the more you can be sure that it is.
| a_square_peg wrote:
| I tend to think most of engineering is rather mundane but
| potentially very rewarding. I hate meetings and overly
| complicated project coordination just as much the next person but
| there is also danger in wanting to do 'cool stuff' - imagine a
| dentist who is passionate about pulling teeth out.
|
| A project that I quite enjoyed involved months of investigation
| work, finally solved by tweaking a single software parameter that
| dictated how far a release mechanism moved. The number of
| internal/external meetings I had to demonstrate that this can
| indeed fix the problem could have seemed silly but it was also
| very reasonable given the risks involved.
| formerly_proven wrote:
| > I hate meetings and overly complicated project coordination
| just as much the next person but there is also danger in
| wanting to do 'cool stuff' - imagine a dentist who is
| passionate about pulling teeth out.
|
| There was a case here were an (employed) dentist was apparently
| bored and started to drill and fill perfectly healthy teeth.
| Iirc, criminal charges were filed.
|
| Malpractice because bored (or feeling
| undervalued/underappreciated etc.) isn't just a problem for
| SWEs, but actual doctors. Also see: nurses and doctors inducing
| code blues to get to be the hero saving the patient; firemen
| becoming arsonists to have a fire to extinguish.
| xpe wrote:
| What are some estimates for the likelihood of these
| behaviors?
|
| In dentistry? 1 of every ... ? 1,000 teeth? More? Less?
| pixl97 wrote:
| Not sure how many good studies there are on it, but the
| likelihood of an unnecessary operation occurring are
| strongly linked to that months financials.
|
| https://www.theguardian.com/society/2000/apr/16/futureofthe
| n...
| ethbr0 wrote:
| > _imagine a dentist who is passionate about pulling teeth out_
|
| That's a _great_ metaphor for code-before-you-know developers.
|
| > _finally solved by tweaking a single software parameter that
| dictated how far a release mechanism moved_
|
| I think of this type of work as programming by other means. The
| problem couldn't have been "fixed" without all the discovery
| meetings and understanding. The "fix" couldn't have made it to
| production without political agreement.
|
| Is that computer code? No. Is it building a solution to
| interact with a complex system (of people), using the
| primitives available to you (less than VP-style "Just do it"),
| to realize a desired outcome? Yes.
|
| Others may be different, but I find hacking obtuse process
| problems and corporate political structures just as fun and
| rewarding as a nice piece of code.
| nickjj wrote:
| > Imagine a dentist who is passionate about pulling teeth out
| ... That's a great metaphor for code-before-you-know
| developers.
|
| A key difference between a big decision and a small decision
| is what it's like to change your decision afterwards.
|
| I don't think we can compare reverting a pulled tooth vs 2
| hours of programming the "wrong" thing.
|
| In the programming case, you may have went down a rabbit hole
| that wasn't correct but at least now you're 1 step closer to
| the right solution. You probably learned something and the
| business can write that off as R&D.
|
| In the pulled tooth case, well, I'm not sure I want to Google
| that haha. Is it possible to fully replant a pulled tooth in
| a way where it's 100% healthy and you'd never notice it was
| pulled? I know there's implants but I mean the real natural
| tooth, complete with its root. I'm sure the process in any
| case would not be fun for the person who needs the work done.
|
| You could classify one of these as a small decision and the
| other one as large.
|
| I still think planning and understanding the problem before
| coding most things is a very good idea btw, but I would feel
| way more comfortable experimenting with code in short periods
| of time vs experimenting in a dental chair / operating room.
| pc86 wrote:
| I maybe wrong but let me paraphrase what I think they meant
| (and why I think it's a great analogy).
|
| I don't want my teeth pulled just because. If it's a fix to
| a problem - a means to an end - and there's _no other way
| to do it_ , I'll consider it. Likewise, I don't want to
| work with developers who are super passionate about typing
| code into vim. I want to work with developers who are
| passionate about _solving problems_. Code can be a means to
| that end, and by the time it gets to us we typically
| already know we need some code for it, but the danger is
| spending days or weeks writing code nobody needs and nobody
| asked for because it 's "their passion."
| ethbr0 wrote:
| Also, I see every custom line of code written as a future
| burden. Part of software engineering is effectively
| minimizing and managing that burden.
|
| If we write 10,000 LoC for something that we didn't end
| up needing... the team's going to be tempted to wrangle
| that into the actual purpose instead of throwing it out.
|
| So overly aggressive fingers on keyboard lead to more
| bloated results, as requirements drift during development
| and more code is written to target them.
| bambax wrote:
| > _imagine a dentist who is passionate about pulling teeth out_
|
| Exactly. Many times, the best code is no code. And making
| decisions about what code to write need meetings,
| unfortunately, or at the very least some kind of coordination.
| Ekaros wrote:
| There is really some questions that should be asked: Why are
| we doing this? For what reason it has to be done this way? Do
| we need to do this at all? What do you actually want? And so
| on.
|
| Meetings are useful to clear up this stuff and at best result
| there is simpler solution, or not need to do work at all.
| ratww wrote:
| However it is often the case that programmers "at the
| leaves of org charts" (to paraphrase another commenter)
| won't get to participate on meetings that can define if
| something can be replaced by "less code", let alone "no
| code".
|
| In small orgs with a headcount of tens that's very easy for
| developers to grasp the value and the need for certain
| things.
|
| But when you're in a 1000+ developer organization it is
| often the case that the reason you have to do something is
| because this is a requirement coming from two or three
| management levels above.
|
| In some orgs, a lowly developer might even be unable to
| even sit at the table with the big boys. They might have a
| say and a good perspective in micro decisions, but not in
| macro ones. In this case, I can definitely see TFA being
| written.
|
| To use the dentist example, imagine a dentist that's
| passionate about pulling teeth, but doesn't get a say on
| wether the teeth should be pulled or not.
| xpe wrote:
| Yes, _some_ kinds of meetings can be useful.
|
| The author of the post, in my reading, laments petty
| meetings not productive ones.
| phendrenad2 wrote:
| A single developer, armed with a correct and final specification,
| can build software far faster than a team. However,
| specifications are constantly changing, and are never complete,
| so the number of developers you need becomes infinite. FAANG have
| deep pockets, so they can push their efficiency from 99% to 99.9%
| by hiring another ten thousand programmers.
| j_barbossa wrote:
| > Believe me when I tell you that I could have worked on the
| entire software myself in 5 months.
|
| I find this way of thinking very short-sighted. It may be true
| that this application can be written in net time in 5 months, but
| much more important than writing code is to know clearly what is
| needed, what users need. Moreover, requirements and wishes change
| over time. I have seen more than once that months of development
| time were wasted on something the users didn't need, so good
| product managers and senior software engineers who question
| things are often more valuable than engineers who write hundreds
| of lines of code a day.
| JeremyNT wrote:
| I think the problem here is that the company has software
| engineers sitting "idle" without any good requirements.
|
| I don't think it's uncommon at all. The "hard" part of almost
| every project I work on isn't the ultimately the code, it's the
| "soft skill" of extracting a good specification from
| stakeholders.
|
| What's the reason for the dysfunction here? It could be that
| the software development team is just overstaffed. Maybe if
| they had lower headcount, they wouldn't be idle so much of the
| time.
|
| Of course, it could also be that there are too many
| stakeholders providing incompatible requirements and muddying
| the waters, and that there's nobody in a position to make a
| decision about the real requirements.
|
| I think it's easy for an organization to misidentify an
| organizational problem as a technical problem, then throw more
| technical headcount at it while ignoring the underlying
| dysfunction. And this is how you end up with "bullshit jobs."
| avereveard wrote:
| > You will be asked to write a documentation for some little code
| you wrote. You will carry out tests. You will argue with your
| colleagues and supervisor on every decision you make.
|
| imagine thinking this is bad, unironically.
| ratww wrote:
| This is not what the article says, however.
|
| You misquoted in order to leave out the fact that the
| documentation is 50 pages, and some of the tests are useless,
| and arguing with colleagues is not always productive.
| avereveard wrote:
| I removed the obvious exxagerations. of course nobody ask you
| 50 pages, so why is it relevant for the discussion? and who
| decides for how much documentation is needed anyway? the
| producer, or who pays for it?
|
| also, you don't know which tests are and arent useless
| beforehand. code coverage may not be the perfect metric, but
| correctness is is semi-decidable anyway, so if one claims
| before hand that some coverage test is useless, he's most
| likely being lazy or drown in his self importance.
|
| and arguing technical decision is always productive, so much
| that rubbe ducking is an actual methodology becuse even
| arguing alone is better than go head down with aggressive
| randomness.
| ratww wrote:
| Sorry but you are wrong. Useless documentation, useless
| tests and useless arguing definitely exist, period, and
| they are tautologically bad. Maybe you haven't had the
| experience of working in such an environment where those
| things happen, but claiming they don't exist and twisting
| someone's words is absurd. Also, those wild uncharitable
| and provocative interpretations are also against the HN
| guidelines.
| avereveard wrote:
| I'm not claiming they don't exist.
|
| I'm claiming they're not universally bad, and that the
| claim they're universally bad is absurd - if unsure about
| the interpretation, please do refer to the initial post -
| you might want to start applying that charitable
| interpretation thing.
| ratww wrote:
| The author himself didn't claim they're universally bad,
| nor did anyone else. The only "claim" for that is in your
| original post, where you misquoted the author on purpose!
| You can't completely twist someone else's words and then
| use that as an argument. And I don't see how referring to
| a post where you're twisting someone's words has anything
| to do with charitable interpretations.
| SassyGrapefruit wrote:
| It's not a charity. Spoilers your company is making money hand
| over fist. Many company's boast a $600,000 or more revenue per
| employee figure. In many cases you are there just for insurance.
| I employ more people than I need on purpose because someone might
| up and leave at any moment and I have to keep operations going
| gherkinnn wrote:
| I get the frustration, but this reads like Programming Sucks [0]
| without the wit.
|
| 0 - https://www.stilldrinking.org/programming-sucks
| oxff wrote:
| I think the inflation / funny money being injected doesn't help
| at reducing fake working.
| ratww wrote:
| It definitely doesn't.
|
| I worked in the past at a company where Softbank asked for the
| dev headcount to be increased as a condition of the funding.
| Lots of teams ended up being responsible for halves of pages,
| half of a microservice, etc.
| dairylee wrote:
| > I remember we would choose to work overtime due our addiction
| to the problem we were solving
|
| Oof, sounds like the author is the joke.
| modo_mario wrote:
| Why? From his description it sounds like he enjoyed it and
| that's probably the best kind of work.
|
| I've spent more time on tooling for myself than i got out of it
| in saved time and learned a ton without pay. Alternatively i'd
| have been paying a match of a videogame that i'd have forgotten
| about by and probably regretted now.
|
| These past days I spent a lot of time doing research into and
| designing an own keyboard at home. Something similar exists but
| is imo overpriced yet i'm not even saving money given all i've
| spent on a soldering iron, etc But i'm enjoying myself just
| creating something that i've gotten invested in.
|
| Meanwhile at work I feel like a damn clerk. Making minor
| changes, arguing, pushing little bits of overhead out of the
| way and working slowly on something i consider an inherently
| inefficient design bound to require a complete rewrite at some
| point for reasons out of our control.
|
| I wish i could go back to those occasional few problems I cared
| about to work just that bit more to get it working. In neither
| scenario I really cared about the overarching company but if
| there was never ever anything to catch my drive like that i'd
| have changed jobs by now.
| plaguepilled wrote:
| I like my own space. I'm definitely introverted. But shit like
| this is inexcusably antisocial and I question why it was even
| posted.
|
| You wanna be a s00p3r lean, high-volume company with actual
| impact? Good luck. 'Bloat' scales with accountability.
|
| That's a bit invective of me so lets play out a scenario. Its not
| a real scenario - this never happens at an actual software
| company, because the incentives all hit each other at once and
| its not explicit. Its not even guaranteed to happen all at once!
|
| But this drama does illustrate the incentives, to the extent I
| can demonstrate a point. Please read the below as an exposition
| rather than a testable hypothesis.
|
| Lets say you wanna be a lean, multinational corp providing a
| crucial service to high paying clients. And you do it! Congrats,
| you, the lead dev, and a CEO who handles 'the rest' now have a
| strong user base, but also a lot of opportunities to be sued if
| your product is actually as crucial as you suggested it was and
| doesn't deliver. Wait.
|
| Oops, you got sued, and you were (morally) in the right too! But
| fined all the same. It's a big fine.
|
| 'Never again' you and the CEO say. So now you need to hire
| lawyers, who advise you that to protect yourself legally, you
| need to monitor your service and have evidence that backs up your
| claims beyond 'we designed it to do that'. So now you have
| analysts! You are monitoring for uptime. For security. For
| correctness. Et cetera.
|
| Now you have an analyst team and a legal team on top of dev.
|
| But eventually your staff base grows. At some stage, payroll gets
| out of hand. An accounting division happens.
|
| Accounting has many jobs. One such job CAN be to lower
| expenditure.
|
| Accounting look at the COGs and notice that the dev team are
| spending money on a bunch of software but there's nothing written
| down as to what it does. They aren't expected to discuss their
| decisions with dev, so they don't.
|
| So a budget is set up by accounting based on their expectations
| from similar industry. Spending on tooling is among those cut.
| Devs complain. Work slows. The analysts complain. The CEO is
| annoyed at the excess spending and the slow devs. The devs are
| mad at how out of touch the CEO is - after all, the accountants
| screwed up right? Why is the dev team to blame? Things were
| WORKING before! Why does she instantly take the analysts word as
| gospel?!
|
| The CEO doesn't care about the devs or analysts to that extent
| though - she just wants the damn product to be shipped to spec so
| the company isn't sued again. But she recognises something needs
| to change.
|
| The natural solution is to air everyone's expectations at once. A
| meeting is made to make sure these show-stopping issues don't
| show up and a cohesive company vision can be reached.
|
| Devs have to spend time in meetings to help accounting,
| analytics, legal, and now marketing (since growth has slowed) not
| tread on their feet, and additionally prevent dev from treading
| on their feet.
|
| Dev team is mad. Not only are they losing coding time, but now
| they feel bossed around by other departments. They were doing so
| much more before these other BLASTED LEECHES came in and spoilt
| everything. Something something 'I could do it better' something
| something. Cue 30 replicas of this article, complaining about
| Working With Other People. If you're lucky, there might even be a
| touch of Ayn Rand laced in. Or Marx! Truly a lottery of
| philosophy.
|
| Eventually some devs break off and start their own schtick, and
| make a decent living for a while - maybe even for a lifetime, if
| the project is well scoped and managed!
|
| But the less cautious startups? Well, if they don't deliver...
|
| What was my point, aside from apparently being a hypocrite who
| can write edgy scenarios but is mad about reading them?
|
| What i am trying to argue is that the other departments are there
| for an explicitly profit-generating or loss-mitigating reasons.
| And more than that: I'm saying this should be fairly obvious and
| that the dialogue needs to move on from this point.
|
| More explicitly: I can understand working for a smaller company
| and enjoy the environment, but the constant whinging about
| megacorps being slow for devs and highly specialised/myopic is
| lazy thinking. Of COURSE they're slow. Of COURSE there's lots of
| documentation and meetings. You get paid a secure and
| comparatively higher wage for those inconveniences.
| pqs wrote:
| All these meetings, reports, plans and apparently useless things,
| provide insurance to the different stakeholders of the project.
| Projects fail in many ways, and you need everyone to feel safe.
| That's why you need to document things a lot, in order to say
| "this was explained in section 3.2.1 of the manual" when the
| other team doesn't correctly use your tools. And this is true for
| everyone, the finance guys, the product guys, the programmers,
| the marketers, everyone. Providing insurance to everyone is very
| expensive, but it makes the large organization stable. If
| everyone worked like cowboys in an small company, then the large
| company would disappear in a large fire of infighting.
|
| I never worked in a large company, but I work in academia, and we
| academics are also working on insurance a lot. The funding bodies
| want us to detail all expenses and justify all the changes in the
| plan, because they don't want people to say that the public funds
| are mismanaged. This is just an example. We also write tons of
| useless papers, to justify that we are productive with this
| money. This makes research very difficult. If you really want to
| do science, you should become rich and do it from home, like
| Nassim Taleb does, but in Academia we must work on all this
| insurance stuff, like in corporate world.
|
| That's how things are.
| popcorncowboy wrote:
| > provide insurance to the different stakeholders of the
| project
|
| A good analogy. The lower trust the environment, the higher the
| levels of insurance required. But it's more than this, it's
| almost like the "busy work" is a form of "Proof of Trust", and
| the lower trust the environment the more Proof of Trust is
| required to be exhibited.
| native_samples wrote:
| Whilst I agree with a lot of what you say, this part:
|
| _> We also write tons of useless papers, to justify that we
| are productive with this money._
|
| doesn't seem to be a logical part of your argument. Writing
| useless papers is not a form of insurance nor proof that work
| is being done. It's rather the end product, what all the
| 'insurance' is trying to ensure gets done. The fact that
| academia outputs a torrential flood of useless papers has
| little relevance to the corporate world where the final product
| is, hopefully, useful despite sometimes being inefficient to
| get there. After all companies that produce truly useless
| outputs do eventually get the rug pulled from underneath them,
| either by bankruptcy or forced sale.
| pqs wrote:
| Yes and no. A scientist should generate knowledge and
| insight, the scientist must discover things. The only way to
| prove that to a bureaucracy is through papers. It should not
| be the end product, but it has become the end product. In any
| case, it is still insurance, if you publish cited papers, you
| are safe, even if their contents are useless.
| jrwoodruff wrote:
| It does seem like that's how things are. I wonder if it's how
| things have always been? And if not, what's changed?
| pqs wrote:
| This is a very interesting questions. I don't have an answer.
| phkahler wrote:
| >> The funding bodies want us to detail all expenses and
| justify all the changes in the plan, because they don't want
| people to say that the public funds are mismanaged. This is
| just an example. We also write tons of useless papers, to
| justify that we are productive with this money.
|
| See how the solution is causing a different form of the problem
| it's trying to solve?
|
| I agree with your premise, but sometimes I think having
| multiple efforts in parallel and letting many fail might be
| more productive than going the safe route.
| frank_nitti wrote:
| I could see that working for a set of moonshot efforts at
| startups who primarily only have to keep investors
| interested, or some subset of research projects at FAAMG
| companies with money to burn.
|
| But how could that work with big companies making contracts
| with other big companies as their customers? Doesn't seem
| like they could afford to just "let many fail" as they could
| lose the customer's trust.
| ratww wrote:
| Big corps doing big projects are already doing risky stuff.
| Those big projects often fail to deliver the expected
| result within the expected time frame and budget.
|
| Devils advocate: Having multiple efforts in parallel with
| the crazy overhead would probably give at least one of them
| a fighting chance of succeeding. Who cares about the ones
| that failed when the whole big project worked for once.
| frank_nitti wrote:
| I see, we are referring to an internal mechanism for the
| vendor to try multiple routes to meet the customer ask -
| this makes more sense, but I could see a lot of
| traditional enterprise customers being hesitant to buy in
| if they were made aware (if you could do it with only the
| partial resources that delivered the "successful"
| solution, why am I paying for the others?)
| phkahler wrote:
| Most software is essentially rented. It already written
| and has zero marginal cost. The vendor is using the rent
| to develop the next version. An exception would be
| specific contracted work, or bug fixes under a
| maintenance contract. How that next version gets
| developed is really up to the company.
|
| Or we can just continue getting great stuff like windows
| 10 and 11.
| woojoo666 wrote:
| Well the original article talks about how the work that a
| software company does in a year, can be done in a few months
| by a freelance developer with zero bureaucratic overhead. But
| which freelance developer? For every freelance developer that
| succeeds, there will probably be ten or a hundred that fail,
| or push out a mediocre product. This is what all the meetings
| and design docs and testing is for. To increase the chance of
| success.
|
| I'm sure the same can be said for the academic world. If I
| was in academia and I was given funding without oversight, I
| would probably waste it all on researching things I found
| interesting but weren't necessarily useful to anybody. If you
| don't want to have to justify your expenses, then just fund
| it yourself.
| HeyLaughingBoy wrote:
| > multiple efforts in parallel and letting many fail
|
| I actually worked for a company that did this for a while and
| the results were amazing. There were multiple tasks, each
| task being a way to improve or cost-reduce a part of the
| machine we built. Each task had 3 teams attempting to solve
| it a different way. We met back 6 months later to
| compare/contrast the outcomes. I've never seen so much
| innovation in such a short time. The job was a blast for
| those 6 months because you were only limited by budget (we
| had to build hardware) and imagination.
|
| And then, of course, since it was a multi-billion dollar
| company, the entire thing got shut down and we went back to
| business as usual. But at least I still remember it 10 years
| later :-)
| d23 wrote:
| > I never worked in a large company
|
| I don't want to be rude, but it sounds like you don't know what
| you're talking about.
|
| It often goes far beyond "insurance." A lot of this stuff is
| performative. Some people simply aren't good at executing, and
| many managers are focused on appearances and increasing the
| size of their kingdoms. Most can't allow themselves to be fine
| setting a roadmap and having it execute smoothly. There are all
| sorts of other perverse incentives and absurd behaviors I could
| go into, but the notion that it's all completely rational is
| silly.
| jenkstom wrote:
| I believe (s/t)he(y) means in the sense of risk management. A
| lot of things are done to ensure that certain risks are
| minimized.
| hcarvalhoalves wrote:
| I don't think it's about safety and stability at all, given how
| CEOs everywhere are _begging_ for their employees to innovate,
| be accountable and take risks. All this insurance is required
| because large organisations tend to devolve into "cover your
| ass" culture. People get automatically promoted by staying, so
| avoiding getting ousted by being someone's else scapegoat is
| the safest bet.
| poulsbohemian wrote:
| >CEOs everywhere are _begging_ for their employees to
| innovate, be accountable and take risks
|
| Executives like to say these things, but what they say and
| what they mean often diverge. The nail that sticks out gets
| beat down.
| drewcoo wrote:
| This. Incredibly risk-averse behaviors indicate an industry
| ripe for disruption.
| Lapsa wrote:
| my favorite - forcing signing "Code of conduct" that pretty much
| says you gonna try to be a good person (as if you were not
| beforehand)
| 867-5309 wrote:
| "Tame in me the tempers four, that I may serve thee evermore.
| Place in me the values nine, that I may feel thy touch divine."
| praptak wrote:
| TFA uses exaggeration to paint things which _are_ necessary as
| superfluous bullshit (write a 50-page doc on every feature). When
| you strip that, you are left with a pretty banal statement: lone
| coder outside corporate environment can work faster on
| implementing stuff than one working on a big project in a
| corporate setting.
|
| Okay, but doesn't everybody know that already?
| t43562 wrote:
| Working with larger and larger groups of people gets harder and
| big companies don't have all the solutions - fortunately -
| because otherwise little companies wouldn't have a chance.
| williamkuszmaul wrote:
| I think that many "software companies" are actually marketing
| companies that plan to make almost all of their profit from a
| product that has already been built. They're not necessarily a
| joke... it's just that software engineering is no longer their
| main business.
| lnxg33k1 wrote:
| I think I had more or less the same conversation with a coworker
| recently, I also have 15+ years experience in building software
| and I think that software is useless and the point to build a
| project by itself in 5 months is naive, software developers have
| a value if the thing they're building serve a purpose, and the
| purpose needs to be defined through meeting people with the
| domain
|
| To me this post has junior dev perspective but also the coworker
| I had the conversation with is in his 40s and I'm starting to
| think there is some generational thing going on here
| thenerdhead wrote:
| Here's something I learned.
|
| Yes working in big tech or a big company can have its fair share
| of red tape.
|
| You can either accept this and work as a cog in the system, or
| you can start to poke the sleeping bear.
|
| When you're overburdened with more meetings than time to do the
| work you talk about in those meetings, that's really on you, not
| the group of humans we call a company.
|
| If your boss starts to attach your performance towards meetings,
| then maybe its time for you to have that conversation about how
| nothing is getting done and that by not accepting meetings is how
| you do get stuff done. It's all about balance at the end of the
| day. Most people are reasonable and will listen.
|
| So while big companies may never change in practice, you can
| change how you work in a big company and see tremendous results
| by just saying "No" every so often. Most of the time nobody
| notices or cares, and when they do they respect you for
| protecting your time to do meaningful work.
| 100011_100001 wrote:
| I 100% agree. It's about creating your own oasis. There will be
| friction from everyone around you, the only way to overcome it
| is by producing results and being very clear about your
| intentions.
|
| Also don't be surprised if your manager / co-workers around you
| forget agreements that have been made. Occasionally you might
| have to compromise, other times stand your ground.
|
| Moreover there is a fine line between poking the sleeping bear
| and acting like a prima-donna because things are beneath you.
| You can't always work on the most complex, or interesting
| projects. Someone has to fix the defects, produce the blue
| widget, now that the red widget is working.
|
| Personally I try to alternate between working on "cool" things
| and a boring but relatively important thing. That way I support
| the team, but also make 10x progress on some things.
|
| Meeting wise, I block out 4 hours a day (if I can) in my
| calendar. If you are using Microsoft Outlook you can setup
| Focus time. There are days that I do end up going to meetings
| during my focus blocks, but I consider it a choice.
|
| Of course I have had multiple honest discussions with my
| manager to manage expectations on both sides. Figuring out your
| manager's main needs / goals can help a lot in those
| discussions.
| wly_cdgr wrote:
| He ain't wrong, in fact he's right. Being a kissless virgin he
| fails to appreciate the importance of UX/UI decisions. But other
| than that, yeah
| gandutraveler wrote:
| I've been in software for 20ish years now and I can tell you that
| beyond couple of years of learning, there isn't anything new to
| learn in software. Every few years same old patterns get wrapped
| under a fancy name and people jump into it thinking it's
| something cool to learn.
| xtracto wrote:
| Right? Young devs are just learning at the marvels of static
| typing languages (python, ruby and type script static typing
| efforts).and then, "server side rendering" (you mean like,
| PHP?) and whatnot...
|
| Having been programming for 30 years I find most of it pretty
| funny.
| TheBigSalad wrote:
| I get annoyed working with people like the author. "Make me code,
| don't make me think". I get that writing code is the most
| fun/rewarding part of the job, but it's not the actual job.
| Anybody can type, figuring out what to type IS the job.
| rob_c wrote:
| Dear author, you're one of those people who are capable of more
| and need to take an unfortunate step back.
|
| Given there are so many people who flocked and are still flocking
| to IT based programming jobs because of the promise that "one day
| you will be the next <insert-billionaire-here>" level push.
|
| I've met people who burn themselves out trying to write hundreds
| of lines of good code in a day. I've had new colleagues come in,
| publically slate my code, only to have to retract their comments
| in private several months later once they actually understood
| what it's doing.
|
| The author is probably one of the types, that left as seniour
| architect could have build something better with people around
| him adding polish and other "perceived value" to a customer.
| (Perceived value in this case being everything from corporate
| branding to translations to internal tooling).
|
| Most "complex" problems from the non-IT world don't need a full
| stack all singing all dancing latest npm, all the RAM in the
| world and a full Oracle site lisence. Most could be solved by
| some talented coders (3 or 4 max) doing the grunt of the work
| with others around them adding perceived value to allow the
| company to add a zero to the net value of the product, and it
| could be deployed in-house on a 2nd hand server with redundancy
| built for <$30k for it's whole lifetime. And that's assuming it's
| not just an app to sell that requires no hosting.
| varjag wrote:
| There's one competent programmer for every 4.2 big thinkers,
| visionaries and non coding architects, so this is a natural order
| of things.
| jleyank wrote:
| These were not "software companies". Such companies sell
| software. These were "normal" companies dabbling about automating
| processes and "being modern". If software isn't what keeps the
| lights on, it's just a playground or a cost centre.
| spamizbad wrote:
| > I remember while I was working for a big financial firm as a
| software developer. I kept asking myself why we were doing very
| little coding. Most of my time was spent attending useless
| meetings, preparing boring slides, making goofy excel sheets and
| Gantt-charts and maybe 1-2 hours of coding a day if I was even
| lucky. The software that I and my team worked on was a basically
| a javascript web application that monitored and collected details
| about financial transactions in the company. Believe me when I
| tell you that I could have worked on the entire software myself
| in 5 months. The entire solution could not have been more than
| 24,000 lines of code (including lots of generated code). My team
| spent nearly 3 years building this software, most of the time
| spent in meetings, bickering over the pettiest feature like, if
| we should display certain data using a particular chart and what
| colour the chart should be.
|
| Theoretically a Product Manager solves this problem for you: they
| are given the authority to be decisive about the details of a
| project, its scope, and they sit through all the boring meetings
| and manage the status update bureaucracy while working with the
| developers to actually build something.
| zmmmmm wrote:
| Another take on it is that in a big company, even incredibly
| mundane and boring software can scale to a level that is
| stupendously valuable once it goes into production. Hence the
| company can completely afford to have an entire team working away
| writing 3 lines of useful code a day. It is way more important
| that the code is created in a way that can mesh with the rest of
| the giant corporate behemoth (so yeah, documentation, meetings,
| etc etc) than it is that it is done fast.
| bumpyliquor wrote:
| >> we were always busy but seldom productive
|
| that. My experience as well. Not on FAANGs but on quite a few
| multinationals.
|
| >> You will argue with your colleagues and supervisor on every
| decision you make
|
| and that. Politics are through the roof and driving out the good
| productive engineers. The people that have little to offer on the
| tech side though thrive in this environment creating a vicious
| toxic cycle.
| badrabbit wrote:
| I work in infosec and I have seen this problem quite a bit but
| not at every company. An advice I received early on was "better
| to ask forgiveness than permission".
|
| So what I do once in a while is, if there is a major problem and
| the bureaucrats want to strangle it or play games like this, I
| just quietly do all the work and say "he, look! It's done!" Some
| will get a bit upset and inevitably my done work takes months to
| get reviewed and discussed before being implemented with no
| change.
|
| It is not good for scoring political points but shit gets done.
| In normal IT or sofware dev, this just means delayed projects. In
| security it means reduced security posture. Bad guys are not
| taking months and years in meetings when they attack us. It in
| itself is a security risk and what I do to work around such b.s.
| in my opinion is remediating that risk.
|
| But regardless of this, bureaucrats will still continually tear
| down and the build backup. Migrations the proof of concept
| meetings and demos. It is very hard to communicate with
| management that in infosec, you need to be agile and stable at
| the same time. Agile when responding to threats but stable in
| your tooling and people so you can develop maturity.
|
| I too like job security and all that but damn it! I would feel so
| shitty if we get pwned and all we have is excuses.
| secondcoming wrote:
| > Believe me when I tell you that I could have worked on the
| entire software myself in 5 months
|
| Sure. People always over-estimate their abilities, and under-
| estimate problem complexity. It's easy to say something like the
| above when you're already looking at the solution.
| darod wrote:
| programmers think their job is to write code, but their job is to
| implement solutions. sometimes those solutions involve pushing
| back and asking the customer to think about their workflow a
| different way, sometimes those solutions involve tweaking
| something existing or fixing a small bug, and other times those
| solutions require writing and fleshing out a whole new
| module/feature/product. the only way you know what the solution
| reduces the risk and provides value to your client is by
| communicating with them.
| amelius wrote:
| It's a sad thing that there is so little money in making
| scientific software; better make some dumb flashy app if you want
| to retire early.
| bayesian_horse wrote:
| Finding out what needs doing - through meetings, documentation
| and so on - is very much a part of software development unless
| there is only one developer and he is also the only stake holder.
|
| This isn't even necessarily inefficient, because productively
| doing work that isn't needed isn't helping anyone either.
| genezeta wrote:
| One place I worked at some years ago...
|
| We had this "important project" coming up, a certain big
| feature that was wanted in the platform. A project which would
| take about 6-9 months with the collaboration of various teams
| across the company.
|
| I was involved but only in a helping role. One member of my
| team was involved but they were fairly inexperienced and so I
| was asked to go in as support.
|
| After the first two meetings a number of things became clear.
| Mainly that the product owner for the project was extremely
| ambitious, clearly not knowledgeable about the technology
| involved and got very upset about any concerns or problems
| anyone would point out. They wanted "those stupid meetings" to
| be just for informing them of solutions and progress, not for
| discussing problems and options.
|
| At the third meeting I made the mistake of mentioning that a
| particular detail, not too important, would be extremely costly
| to do as asked and that we would be better off doing it in a
| much simpler form. Unbeknown to me, that day the product owner
| went behind my back and asked for me to be immediately removed
| from the project. So I was. I didn't care much for it and I
| only learnt about that move much later, when I had already left
| the company.
|
| Anyway, the project ended up taking about 2 to 2 and 1/2 years
| and it had to really reduce its scope in the end. And some of
| the people involved confessed that it was because of the
| product owner, because they had wanted people to "just build
| this thing I say and stop arguing". A lot of work was simply
| thrown away several times simply because of not having had the
| proper discussions it needed.
| lupire wrote:
| Yes, some product managers or whatever are terrible at there
| jobs, just as some programmers/engineers are.
|
| Doesn't mean the job role is useless.
| genezeta wrote:
| I don't really care much about what role was responsible. I
| commented it more for the usefulness of
| discussions/meetings.
| thawaya3113 wrote:
| One of the big differences between a startup and a big company is
| that big companies have to make decisions about what to build.
| For a smaller company that decisions is already made. It's the
| reason for the existence of the smaller company.
|
| And the cost of making the wrong decision can be extremely high
| and it can be hard to both identify that it is the wrong decision
| and to reverse it.
|
| With smaller companies if they make the wrong decision they will
| simply cease to exist, but in a larger company some other product
| (the one that made the company large in the first place) will
| cover for it.
|
| This isn't to excuse inefficient practices, but the idea that
| 100% efficiency (as defined by coding 100% of the time) or even a
| very high coding throughput is an unmitigated good is not really
| valid.
| randomsearch wrote:
| I'm super sceptical of such articles. The hardest part of
| software development is knowing what to build, and that requires
| a highly skilled product manager. The latter is a full time job
| for even small projects with a handful of devs.
| promhize wrote:
| albertTJames wrote:
| The guy made "only ennemies" in big companies. Not sure he'd be
| the most unbiased person to comment on the quality of tech jobs
| or somebody who can comment on healthy coworker relations.
|
| When the same pattern keeps happening to you wherever you work,
| its not them, its you. That you had a few good positions in
| healthy teams does not make you a healthy coworker, the culture
| was probably just too strong and healthy for you to mess it up.
| mmcgaha wrote:
| This is why a lot of programmers work after 5:00 PM. You can get
| more done between five and nine than you can get done all day.
| lurker531 wrote:
| lurker531 wrote:
| Imagine actually caring, my aim is to get away with as little
| work as I can while still earning good money. 'No nonsense coding
| and learning' cringe, imagine actually liking to write software.
| After 11 years of embedded dev, I can safely say I rather not
| write a single line of code ever again. This whole industry is
| 99% bullshit. Thankfully I could exploit it for a lot of monetary
| gains
| BeFlatXIII wrote:
| As a worker, I like your attitude. As a manager, my attitude
| toward your attitude is entirely dependent on your competence.
|
| Nothing wrong with viewing work solely as your means for
| funding the important parts of your life.
| lurker531 wrote:
| I've been employed at my current company for 6 years now, I
| do what needs to be done but my feelings are stated above.
|
| Complete opposite to when I was a bright and hopeful fresh
| graduate
| commandlinefan wrote:
| > imagine actually liking to write software
|
| I assumed you were being sarcastic, but re-reading your post
| and looking at the replies, I guess you're being serious here -
| I _do_ actually like writing software. I 'm not pretending or
| fooling myself - besides playing music and raising vegetables
| it's one of the few SFW activities I actually enjoy. I tolerate
| meetings because they're part of the price to get to write
| software and actually get paid to do it. What I don't enjoy are
| the unreasonable expectations around how long things ought to
| take or how predictable software development ought to be.
| reallscoliosoi wrote:
| I agree. Actually, I have never met anyone who has liked
| writing code. How much code do any of these high profile
| programmers even write anymore? Linus, etc? If the leaders of
| the industry don't even write code, it says a lot.
| aurbano wrote:
| I've been writing code for 16 years, which is now over half
| of my life.
|
| I've been a full time software engineer (now lead) for the
| last 9 years. I've been in similar situations to this article
| where most of my time was spent in useless meetings that I
| disliked, I tried to improve things, to focus meetings, to
| improve our efficiency.
|
| And all that aside I still love coding. Granted not all types
| of code, not the one I have to write sometimes at work.
|
| Just now I'm starting another little fun side project that
| I've been coding on my free time these last few weeks.
|
| All this is to say that coding is just a little tool, what
| you build with the tool is what can be fun. I think it can be
| healthy to write code that does fun things from time to time,
| even if the code you write at work is for the most boring
| aim.
| dahart wrote:
| I love writing code, nice to meet you. I know lots of people
| who love writing code. (Side note I also do see the value in
| meetings too.) I work with some relatively high profile
| programmers in my field (computer graphics) who still write
| _lots_ of code, and will continue to do so until they retire.
|
| Linus doesn't write any code, in his own words, but that's in
| part because his knowledge of software makes him better at
| leading people than writing code now. But Linus is not all
| leaders of the industry, many of them still do write code.
| John Carmack still writes code. That said, why should high
| profile programmers continue to code? What exactly does it
| say if they move into management?
| Der_Einzige wrote:
| I'm glad someone else said it. I want to think of problems
| that other people write the code to solve for me. I'm so
| tired of having an idea and no one but myself to work on it.
| It's led to a nice GitHub portfolio but I'd have rather that
| the stuff I built had existed already.
|
| This is mainly because most other people can execute with a
| better level of completeness than I can in the context of
| open source dev. This is mainly because I don't actually like
| programming, but I sure as shit love the niche I am
| programming for...
| da39a3ee wrote:
| You have to learn to say no to pointless meetings. It's true that
| there are many stupid people who will try to hold them and they
| have to be corrected. Usually saying "I won't contribute anything
| valuable and nor will I gain anything valuable, so it's not the
| right use of company resources" will suffice. This means that you
| have to develop your skills so that you are not scared of acting
| like that (not scared of being fired). It's ok to be fired /
| leave a company -- the goal is to not be scared that you can't
| get a better job if they fire you for pushing back about
| meetings.
| Juliate wrote:
| One of the main reason I have come to to make peace with that, is
| that these companies are not optimizing for delivery and product
| quality first.
|
| They are optimizing against risk (of change, of loss of control
| over the whole process from ideating to selling/shipping).
|
| If you can build the product/service in 2 months with a tight
| focused team of 3-5 people, in a 100+ engineers company, how do
| you manage if this 3-5 people leave (whatever the reason): how do
| you manage to infuse their experience/expertise over the thing
| they built, to 10/20/30 other people to mitigate then this risk?
|
| You can manage to do so when your company grows, because... you
| don't have a choice, you started small.
|
| When you've grown already, to mitigate this risk, you have to
| start to infuse things across many people and layers of people
| you have, so that when, 3-5 people leave, it's almost barely
| noticeable an event.
|
| Maybe there's a better set of reasons. But this one made me
| understand better the whole world of big corporations and
| especially (big) consulting sofware companies (which are often
| several ones contracted on the same big projects).
|
| Edit: you may also understand "optimizing for" as "scared to
| death about".
| jokethrowaway wrote:
| I disagree.
|
| In most of the large companies I worked for there was zero
| documentation (+1000 employees, +100 engineers) or very very
| little or only in a few projects. When people were leaving,
| someone else was getting hit with a shitty undocumented
| project, they would spend some time learning it - and that was
| it. In the worst case a doomed-to-fail-rewrite started and
| troubled the team for a couple of years.
|
| I think the main issue is that: - People are given tasks from
| the board of directors (trickling down layers and layers of
| management), they don't feel like it's their problem - There is
| little accountability, tracking performance is very hard; tons
| of companies don't bother, but some of them do (after HR
| intervention, CTO being in trouble justifying the costs) and
| they can't find decent metrics to use for performance, so the
| bosses are basically flying blind / trusting middle managers. -
| No high growth stocks that will make you rich - Middle managers
| feeling like they need to prove they're doing something
| imposing weird and useless rituals: meetings, presentations,
| etc
|
| These factors allow people to slack off as much as they can and
| take as long as they can to do anything.
|
| As long as they can come up something for standup, it's all
| good.
| Juliate wrote:
| This does not look like disagreement to me, but rather a
| distinct perspective of the same thing (was it the issue, or
| the symptom?).
|
| Getting hit with a shitty undocumented or doomed to fail
| project is part of the problem/risk being managed or not: on
| some occasion, it can kill the team/project/company, on some
| other, it can be managed more or less successfully, but still
| in a way that is _not regular_ against the baseline.
|
| When you get a project handled by a larger team of people
| apparently doing "not much", 1/2/3 of these leaving will not
| change the baseline of the project they were working on (or
| if it does, then comes the pressure to reorganize again to
| avoid that disruption).
|
| It's "a bit" similar to the 40% lazy ants thing
| (https://boingboing.net/2017/09/12/living-larders.html).
| sam_lowry_ wrote:
| Here are a few personally lived counter-examples:
|
| 1. a unicorn where someone implemented a a CI/CD system that
| none else can work with nor comprehend
|
| 2. a public institution where dozens of people work against the
| clock to replace the software maintained by a few old farts
| close to retirement
|
| 3. a critical financial institution where secrecy and nepotism
| made anyone with 30+ years of service into a major failure
| point.
|
| IMO, the bigger the organisation, the more they are shifting
| from internal risk management to outsourcing all risk. When the
| risk is handled by third parties via contractual obligations,
| life get easy for middle management.
|
| Needless to say, many of those contractual obligations are not
| worth the paper they are written on. Many organisations survive
| largely on the good will of the lowest-rank employees.
| regularfry wrote:
| That would be justifiable if the risk was proportional to the
| cost. Frequently it just isn't.
|
| As a case in point, if "when, 3-5 people leave, it's almost
| barely noticeable an event" then you've almost certainly over-
| compensated for the general case. Why? Because the entire set
| of people who know anything about a given project
| simultaneously leaving should be incredibly rare. If that's
| your benchmark event probability, and your risk mitigation
| costs are linear in the risk probability (which they probably
| are, by vague handwavy analogy to finance thinking), then
| you're constantly bearing costs that aren't justified by the
| downsides you're likely to encounter unless the specific
| project in question is company-breakingly critical.
|
| If an entire dev team up and leaving _isn 't_ a rare event,
| you've got deeper problems.
| WJW wrote:
| I think rather frequently the impact of such a "rare" event
| could indeed be company-breakingly critical, depending on
| which part of the company that team was running. As a thought
| experiment, if all DBAs left tomorrow and the database fell
| over the next day, how much time would the next-most-capable
| person need to figure out the backup policies and scripts,
| restore the db and bring everything back up? I've personally
| seen this sink a company outright. It's only anecdotal
| evidence ofc, but it is still something that happens.
|
| Worse, people leaving a team are not independent events.
| People leaving a certain team is often highly correlated to
| other people leaving the same team, because there is some
| common cause like a toxic manager.
| Juliate wrote:
| "should be incredibly rare". Not incredibly, it's rare, but
| it happens (seen it in two small companies, it killed them;
| saw it in several ESN/consultancy projects, it killed the
| contract, but was a manageable event in the whole company;
| saw it in medium software companies, it killed the projects
| and sometimes pushed for strategy changes).
|
| It happens enough for many (not all) individuals to have
| noticed across their career (especially when in management,
| where a big part of their role is already to manage risk).
|
| It happens enough for any single company to be quite
| traumatized by it when it happened, and to try to avoid it in
| the future.
|
| Where some companies do it differently is: they don't
| overreact, they understand that this is a risk management
| issue and that you can balance it, and/or they don't setup a
| "general case" for all projets/teams (depending on the type
| of the project). This requires quite some serenity and
| perspective.
| emteycz wrote:
| This incredibly rare event has happened at almost every firm
| I've ever worked at (except small startups), multiple times a
| year (different teams/products, but sometimes also the same
| product with its new team)...
|
| Yeah they should fix the actual issue many layers above, but
| that's not something the guy planning for this can do at huge
| corporations. You just deal with whatever it throws at you.
| regularfry wrote:
| Interesting. I think I've seen it once in a 20-year career.
| Juliate wrote:
| That also explains the "design by committee" thing and the
| ugly/desperate UX some corporate apps have.
| reallscoliosoi wrote:
| Every company I have worked at has been the same - very depressed
| people who have no enthusiasm for anything slowly dying as they
| sit there staring at the computer. It is in stark contrast to the
| physical labour jobs I have had, which have been very lively and
| happy places to work.
|
| I think the assumption that these people want to program for more
| than 2 hours per day is probably wrong, and you will just burn
| yourself out trying to do 8 hours of programming every day. In
| fact, many of these people burnt out long ago and just try to
| find anything other than programming to do.
|
| I wonder though, it is true that these companies are very
| inefficient, yet they never get taken over or superseded. Why
| can't the group of rogue programmers that are more productive
| take over any of these companies?
| throwaway235203 wrote:
| I work in bursts. I probably code 1/3 of the work week. The
| rest is spent on meetings, helping others, looking at logs/data
| and keeping up to date on tech. I think that is a healthy
| balance. There are many ways of adding value to a business.
| mytailorisrich wrote:
| > _Every company I have worked at has been the same - very
| depressed people who have no enthusiasm for anything slowly
| dying as they sit there staring at the computer. It is in stark
| contrast to the physical labour jobs I have had, which have
| been very lively and happy places to work._
|
| They even made a movie with that premise (Office Space).
| mellavora wrote:
| Interesting observation. I wonder how much of the difference is
| between high physical activity, where often the work requires
| multiple people manipulating the same physical object (I hold
| the door, you attach the hinge),
|
| vs
|
| low physical activity, where often the work requires multiple
| people manipulating highly abstract concepts with purely
| imaginary connections (I write the API, you write the caller).
| ethbr0 wrote:
| The physical/non-physical distinction might be a bit of a red
| herring, as this seems more a differentiation between
| repetitive and non-repetitive work.
|
| I.e. assembly line worker vs carpenter
|
| I'd hazard most people tend to dislike repetitive work, if
| they have the choice.
| BeFlatXIII wrote:
| It's the middle ground that is mind-destroying. Extremely
| repetitive work lets you turn your brain off or redirect it
| to more worthwhile thoughts. Non-repetitive work keeps your
| brain engaged with the task at hand. The middle ground
| requires too much engagement to focus on other things but
| also leaves too many gaps to remain focused on the nominal
| task.
| m3047 wrote:
| Our minds generally don't work well on repetitive tasks
| requiring high concentration with low interactivity. Yet,
| we're so irrational we can't see the obvious.
|
| Take a "self driving car". Except... you can't really crawl
| into the back seat and eat lunch. No. Are you kidding me?
| You have to pay attention! You have to be ready to grab the
| wheel! A walrus could be napping on the freeway! Just
| because it's self driving doesn't mean you don't have to
| pay attention! Good god, what's wrong with you?
|
| What's wrong with us, collectively, is we don't immediately
| recognize the absurdity of what they're saying. There's
| really something very very wrong with that person.
| bigDinosaur wrote:
| Yes, although repetitive physical (exertive) work is a bit
| less soul destroying if only because it makes you too tired
| to think about it too much.
| ethbr0 wrote:
| As someone who has dug ditches in Georgia clay, agreed.
|
| Although I guess even the most repetitive physical task
| still has infinite physical fidelity, if you look for it.
| E.g. digging a hole in the same place 50 times vs writing
| the same code 50 times.
| lupire wrote:
| People burn out on programming for two reasons:
|
| 1. For whatever external or internal reason, they fail at
| writing good software for a long time
|
| 2. The job takes a terrible physical toll (lack of exercise)
|
| Neither of these are improved by larping at corporate business
| stuff around the office.
|
| Maybe line cooks at slow restaurants have fun getting high and
| chatting while they cook, but many many jobs are physically
| painful, intensive and low-rest, and/or high stress and bad
| hours service work.
| yunwal wrote:
| I feel like line cook is the worst example of a fun physical
| job. Most of the line cooks I know are incredibly burnt out
| and survive their 12 hour shifts by abusing cocaine and
| amphetamines. Landscape contracting seems much tamer by
| comparison.
| exabrial wrote:
| > Many
|
| Most
| Joel_Mckay wrote:
| Sometimes entrepreneurs start a company as a joke hobby while
| working in a coding pressure-cooker. Then a decade later end up
| growing up with clients in a completely different sales field.
| For sure, it is easier to complain, than to take responsibility.
| =)
| mc4ndr3 wrote:
| Third week into a role. Managers too busy to meet. One reports
| that we have no product owner, no audience, and no requirements.
| The other demands a confident promise to deliver the app by Q3.
|
| I recommend trimming the "MVP" to focus on just one, concrete
| user need, so that we have a prototype to deliver.
|
| Manager: No, just stub 99% of the REST contract and get it to
| prod.
|
| With each new software role, I feel I am somehow moving backwards
| compared to the relatively well positioned earlier roles.
| phendrenad2 wrote:
| I feel this too. At an earlier role we had a well-architected
| PHP codebase that we were throwing away and replacing with
| graphql, scala, and angular. I was a junior dev so they threw
| me into fixing the "unimportant" legacy PHP system (which just
| so happened to be the thing making money for the company)
| instead of the shiny new rewrite. Never been happier in my
| life.
| mihaaly wrote:
| Software engineering is a group effort with lots of components
| other than coding. It is very very seldom a lone operation and
| all those are tiny products with tiny scope (if results in a
| viable product at all!). Deciding upon the features, figuring out
| what is the best to do in a plethora of criteria involving
| finance, technology, organization takes much longer than the
| actual coding and involves the communication (spoken, written,
| presented, etc.), no suprise there.
|
| Management could many times done better of course, managers are
| as lazy or incompetent as other people, if not more.
| gray_50 wrote:
| I've worked at all company sizes from big tech, scale ups, and
| early stage startups. From my experience, I've learnt the most
| and done a lot of interesting work when the company size was
| smaller. Although a lot of people seem to care most about what I
| did at the big tech company and get surprised when I tell them I
| spent the whole sprint fixing some line on some sub menu.
| bradlys wrote:
| I have been in a company that is similar to one of these but the
| codebase was massive and very problematic - a good reason for why
| it was hard to get things done.
|
| I think many folks here think if you work for FAANG or similar -
| it's all cushy and you're sitting on fat stacks but it just
| isn't. You'll get on a PIP real fast because you didn't have
| impact - something which was out of your control because your
| boss assigned you a low impact feature. You'll be kicked out
| within 1-2 years and back to the grind - meanwhile stressed and
| possibly underpaid because no refreshers and no salary bump.
|
| Again - it sounds nice in some ways but it's a mostly brutally
| toxic environment and the bar to get hired is exceptionally high.
| If you're getting repeatedly hired at FAANG and crew - you're in
| the top 1-5% or so and it's a very competitive bracket to stay
| in. Seen many go in and never be able to get back in...
| mattwilsonn888 wrote:
| What is this mythical concept "Business Value" which floats
| around undefined, unquestioned, in the impassioned rebuttals to
| this post?
|
| If I can hire one person instead of ten to finish software in one
| third the time, even if it needs significant tweaking by the end,
| is that not "valuable" to my business? Please define and expand
| your terms.
| drdrek wrote:
| His Dilbert level insights about corporate life are very old...
| running a business is complex and gets less efficient with
| size, that is no great wisdom.
|
| Building a code project with one person is great but consider
| the following issues: 1) Making sure the software is built to
| specifications 2) What happens if he leaves? 3) What happens if
| another urgent project arrives 4) Who will do support? 5) Who
| writes documentation 6) What about integrations with other
| systems in the business 7) What about IT/DevOps and server
| maintenance? 8) What about communicating it to other people in
| the org? I'm sure we can find more.
|
| The generic use of term "Business Value" in this instance means
| that while development time is indeed a measure of efficiency
| it is only a small part the overall value that a company needs
| in a project.
|
| Just to make sure I'll state again, large corporations are
| indeed not very efficient, I do not argue that, but they are
| profitable.
| dahart wrote:
| Business value is defined by the business in question, and
| what's valuable to one business isn't valuable to all
| businesses. The point is that the goal is a collective goal and
| not an individual goal.
|
| If you really can hire fewer people to get the job done, and
| the value you care about is lowering the costs of employing
| people, that certainly is valuable, and you should do it.
|
| Business Value is a term you learn to understand very quickly
| and deeply when you start a business and hire some opinionated
| programmers who complain loudly about having to talk to others
| and document what they work on, and proceed to have trouble
| meeting their deadlines, or create issues that others need to
| help fix.
|
| I've personally watched what happens with programmers who write
| code without talking to people enough, both individual
| programmers who seems prolific, and groups of programmers
| working on different parts of a larger system. When programmers
| refuse to stay involved in the discussion of what do to, they
| sometimes invent or imagine their own requirements, and they
| build things that don't fit into what the business actually
| needs. This can be a colossal waste of time and money, even
| though all programmers involved were happy and felt like things
| were "efficient".
|
| The problem with the article is that the author is arguing for
| personal efficiency, at the expense of group efficiency. It's
| funny to write something about software companies being a joke
| and then argue that it's annoying to work with other people.
| The software companies that are a joke are the ones no longer
| in business.
| drdrek wrote:
| Companies are a business and not academic or artistic
| institutes... while developer wellbeing can contribute its not a
| goal on its own.
|
| If those 20 employees work on a bullshit project that could be
| done in a month, but at the end of the day generates tons of
| revenue its a good business endeavor. Could it be done more
| efficiently? Sure. Is it a better business venture than a work of
| art C++ code that was done super quickly but made no profit? Also
| yes.
|
| He has some good points hidden in there but his developer centric
| view is so 90's I wonder if he was wearing a jeans jacket writing
| this.
| agounaris wrote:
| I was expecting to find some interesting thoughts on this one,
| but its the usual rant of the "freelancer" who does not
| understand what production means!
|
| Yes big companies have productivity issues, however they have to
| create software which will outlive most engineers working at the
| business. You cannot reach the SLOs of google by hacking
| something together in 2 months!
| ChrisMarshallNY wrote:
| They are correct.
|
| It doesn't matter, and nothing will change in large corporations.
| That's not a bad thing, or a good thing.
|
| It's just the way things are.
|
| I spent most of my career in large corporations; many of those
| years, as a manager, where it was my job to maintain all that
| overhead the author complains about. I'm quite aware of the need
| for it, and a good part of my job, was trying to streamline the
| overhead, and shield my coders from it, so they could get more
| coding done.
|
| Nowadays, I work on my own (mostly), and the difference in
| productivity is _amazing_.
|
| I remember when I first read _The Agile Manifesto_ , I was, like,
| "These guys really _get_ it! " It was a dawn of a new era. The
| scales fell from my eyes. There was hope! There was a light at
| the end of the tunnel!
|
| The headlamp of the 5:15 Express, out of Sheboygan.
|
| Seeing how "Agile" is being implemented in corporate (and also
| small corporate wannabe) shops kinda took the wind out of my
| sails.
|
| But large corporations seem to get done what they need getting
| done. Very often, it's fairly "klunky" stuff.
|
| But that gives small shops an "in." If they can speak to the
| customers of these corporations, they could make some sales.
|
| Then...it comes time to scale.
|
| Let the meetings begin...
| ejb999 wrote:
| >>Seeing how "Agile" is being implemented in corporate
|
| Dictionary definition of agile: "able to move quickly and
| easily."
|
| There is nothing 'agile' about how 'Agile' is being done in
| most/many big corps - yet another buzzword sold by high priced
| consultants who like buzzwords, to top-level execs that think
| they know what they want.
| knotofvipers wrote:
| One large corp I worked at, agile was really just an excuse
| to use minimum viable products in production.
|
| We were agile until this shitty software was in production
| and then we would move on to the next project.
|
| That was literally what we were calling having a startup
| mindset.
| AtNightWeCode wrote:
| I agree in general. But the business is not a joke. It is a
| farce.
|
| Why have one time reporting system when you can have two or
| three? Why not also add some burndown charts to that so you must
| report every hour left of that ticket? Why not add an additional
| spreadsheet with the same info while you're at it to get a
| "holistic view"? Make it two or three different spreadsheets btw
| so you can separate progress from work hours and gummy bears.
| Cause abstractions are important CS.
|
| "Gummy bears" is of course named different in each project.
| Remember to not mix up the gummy bears with mentos and the
| skittles. Some random management person will get insulted
| otherwise.
|
| Then the boss tells you to only work on the highest prioritized
| tickets. 2 minutes later the same boss mails you a side-quest
| that takes a day. Then the same boss asks why you have not only
| worked on the highest prioritized ticket.
|
| Then you show the boss 5 tickets and ask: What is the highest
| prioritized ticket? The boss replies: They are all the highest
| prioritized. Then you start to work on one ticket and the boss
| asks about the progress on another ticket 2 hours later.
|
| Then the boss calls you into a meeting. The meeting is set for
| just 20 minutes but you quickly realize that there are a lot of
| people in the meeting. The meeting is about some design that
| nobody was prepared for, so everybody must read up and improvise.
| 2 hours later it is decided to apply the same kerning on each
| heading. What the problem was or what the solution solves nobody
| knows.
|
| Now you get an encouraging email about what success that meeting
| was. But the day before some marketing person without prior
| notice or permission managed to do a fundamental configuration
| change leaving the system offline. You fixed the problem and
| saved the company tens of thousands of dollars even though it was
| outside agreed work hours. Then you get criticized by the boss
| because "the system is supposed to work".
|
| And this just repeats over and over.
| miav wrote:
| As the top comment points out, the author comes off as arrogant
| and their view is unbalanced, but they do have a point.
|
| I find the saying "What a programmer can do in a month, two
| programmers can do in two months" is quite true. I consider
| myself competent and the people I work with are even more so, but
| human communication is always very imprecise and slow. If you
| stack it into a hierarchy of teams and managers, efficiency loss
| becomes exponential.
|
| I really do think that the best way to organize software
| development is to have discrete components with exactly one
| person in charge of a component. Of course there are notable
| downsides. If only one person is in charge of a component it
| would become quite opinionated and it would be difficult for devs
| to spot each other's errors, but I think it would be a great
| tradeoff nonetheless.
|
| I really don't want to spend even 5 minutes of my life debating
| whether we should split a folder into 2 smaller folders or not.
| I'd much rather have any member of the team go with their gut on
| this. An individual's choice may not be as good as that of the
| entire group, but it's good enough.
| rrdharan wrote:
| This approach involves a high degree of risk, i.e. your bus
| factor is 1: https://en.m.wikipedia.org/wiki/Bus_factor
| miav wrote:
| Yes, absolutely. Having a single person do what they want
| with a component involves risks but I think they can be
| managed.
|
| Say the dev in charge of an important component of a service
| is struck by a bus and dies. The optimistic scenario is that
| the code was well enough written that people developing
| adjacent components (ie. components that interface with that
| of the deceased dev) can effectively take over development in
| the short term until a new owner is found.
|
| A more interesting scenario is that in which the dev abused
| autonomy and the component is utter spaghetti. In all but the
| most extreme of cases, the component could be kept in
| maintenance mode as is for some time. This would block
| progress that relies on changes in the component, but allow
| the service to continue working. In that time, other devs
| could either untangle the spaghetti and refactor the code
| into something workable or rewrite it. In both cases a
| significant amount of resources would be spent, but this is a
| scenario that's unlikely to occur often and the fact that the
| component was owned by a single person places a soft cap on
| the size of the component (and ideally an employee would
| maintain a couple of unrelated components to ensure they can
| continue working if one service is deprecated) ensuring it
| could be replaced within reasonable time.
| DantesKite wrote:
| What a great writer. He has a bunch of other insightful essays I
| really enjoy too. Thanks for the post.
| gsibble wrote:
| This is why I primarily prefer and frequently am the lead on
| backend APIs. There's no BS. I spend 90%+ of my time coding and
| architecting the system. No bickering, etc.. Here's the API, now
| use it. It's a great little niche.
| rswskg wrote:
| Having recently disengaged from full stack/front end, I have to
| say that I agree with this.
| ZephyrBlu wrote:
| I was reading https://danluu.com/sounds-easy again today, and
| when reading this article I was reminded of a particular section:
|
| _" Everything we've looked at so far is a technical problem.
| Compared to organizational problems, technical problems are
| straightforward. Distributed systems are considered hard because
| real systems might drop something like 0.1% of messages, corrupt
| an even smaller percentage of messages, and see latencies in the
| microsecond to millisecond range. When I talk to higher-ups and
| compare what they think they're saying to what my coworkers think
| they're saying, I find that the rate of lost messages is well
| over 50%, every message gets corrupted, and latency can be months
| or years"_
|
| Dan goes on to say: _" When people imagine how long it should
| take to build something, they're often imagining a team that
| works perfectly and spends 100% of its time coding. But that's
| impossible to scale up. The question isn't whether or not there
| will inefficiencies, but how much inefficiency. A company that
| could eliminate organizational inefficiency would be a larger
| innovation than any tech startup, ever."_
|
| Communication scales extremely poorly compared to code and large
| organizations require a very different skillset than small
| companies. The author seems like someone who just loves writing
| code as opposed to wanting to deliver maximum business value (As
| defined by the company), so it makes sense he dislikes big
| companies.
|
| There are also good and bad big and small companies. A well run
| big company is still going to have a large amount of
| communication overhead vs a small company.
| gone35 wrote:
| Don't see how politics or "bickering over the pettiest feature
| like [...] what colour the chart should be" is what
| "deliver[ing] maximum business value" is about, as you put it.
| thawaya3113 wrote:
| The amount of energy and time spent on "politics" or
| "bickering over petty issues" is usually highly overstated by
| bloggers.
|
| It's easy to understand why. The 15 minutes spent bickering
| over the color of a button will be far more likely to leave
| an impression and remembered vs the 90 mins spent on
| ordinary, necessary and useful discussions in the same
| meeting.
| janejeon wrote:
| Eh, it's been causing a lot of issues over a _long_ period
| of time at least in my workplace, and it 's been dragging
| projects that should've been 2-3 days to 2-3 WEEKS.
|
| I'm sure it varies for people (which is why you're
| downplaying it), but for at least some of us, it is simply
| the truth, the reality we have to face every day we go to
| work.
| Beltiras wrote:
| I was having a discussion with one of the people higher up in
| the org chart about why we need to move beyond a pizza-box
| development model. Currently what happens is that the CEO
| (small org, 10 people, he's effectively the CTO) makes small-
| talk with a dev about a feature that needs to be developed. The
| dev then goes and builds the thing based on the discussion (a
| week-10 day sprint), takes the resulting work to the CEO which
| will then flesh out what needs to happen in addition to the
| work done. There will be some iterations of this process until
| the code can be merged into main and the feature completed.
| It's not horrible really but it can be way more efficient. I'd
| really like it if we can move beyond this seat-of-the-pants
| programming and have a more robust documentation process. I've
| been a part of feature mills like that, I've built my own
| products (unsuccessfully business wise) and I've also done
| contracted work. Out of all of these I was most productive when
| doing contracted work. I think it was due to the customer
| having to really spell out all of the things wanted in the work
| product. The requirements analysis was far better than anything
| else I've ever touched. I don't know why it should be any less
| detailed when it concerns your own work. You should beforehand
| be certain that you know what you are about to build. You
| should state it in a document. The stakeholders should sign off
| on it being what they want built. All of this takes time and it
| should. The engineering part of it is mostly trivial. The hard
| part is building a consensus on what should be built.
| claytonjy wrote:
| That description of "pizza-box development" (unfamiliar term
| for me) sounds pretty good actually? Seems pretty agile:
| informal planning, time-boxed sprint, revisit with
| stakeholder, repeat. It gets so much worse when the
| implementers are further from the stakeholders or customers.
| What's the issue there?
|
| I've also worked in consulting and appreciate the explicit
| requirements, but I find the formality much less efficient
| than the process you describe earlier. It ends up being very
| "waterfall" and exactly the approach the Agile Manifesto
| attempts to counter.
|
| Perhaps you prefer a more waterfall, hierarchical development
| process, or the companies (big ones) or industries (highly
| regulated) that necessitate it?
| Beltiras wrote:
| Buy a pizza for the devs, rip off the lid, sharpie draw the
| sprint on the lid while eating the pizza.
| claytonjy wrote:
| As long as the next pizza lid doesn't contradict the last
| one, that sounds like a good early-stage startup process!
| eastbound wrote:
| Even if it does, it means we've learnt something in the
| middle. And at least the first box was in production.
| commandlinefan wrote:
| > a week-10 day sprint
|
| A week-10 day sprint on _one feature_? They haven't drunk the
| scrum kool-aid yet. Just wait until they do - then every
| feature will be a "story", and no individual story will be
| allowed to be assigned more than 8 "story points" (which for
| some reason means "one day"). If you think a "story" will
| take more than 8 "story points", you'll be asked to break it
| down into "subtasks" of no more than 8 "story points" each
| (you'll be asked to do this accurately in a few minutes in a
| standup meeting). Trust me, if you tell a higher-up non-
| programmer that there's anything wrong with the development
| model, they'll hear "we need to move to the 'scrum'
| everything-is-mandated-to-take-less-than-a-day development
| model".
| AndyMcConachie wrote:
| Is there anything new ever written in this space or is everyone
| just repeating what Fred Brooks said in the 1970s?
| snarf21 wrote:
| Well said. I think the key point you make is that we are paid
| to maximize the value of the _business_. If the business isn 't
| profitable, we could all lose our jobs. Too many IC feel that
| if the company isn't maximizing their _personal_ effort they
| are inefficient and wrong. However, sometimes more value can be
| added by _NOT_ writing more code or more documents. It is
| sometimes more valuable to throw away a bunch of completed work
| and not fall victim to the sunk cost fallacy. Sometimes a
| "worse" architecture is the highest BV.
| pydry wrote:
| It's kind of trite to say that though. It's the business's
| job to ensure that the skills and resources at its disposal
| are put to good use, not yours.
|
| We're not all a bunch of mini CEOs.
| __turbobrew__ wrote:
| In my view the most effective organizations are made up of
| mini CEOs.
|
| When you read about organizations which were highly
| effective there is usually a common theme of management by
| objective and giving people ownership. "The HP Way" and
| this speech by Rickhover are two such examples:
| https://govleaders.org/rickover.htm
| jenkstom wrote:
| An excellent illustration of the difference between a
| professional and an employee.
| frank_nitti wrote:
| From what I understood, they are talking about the author's
| complaint that he doesn't get to spend 100% of his workday
| coding/testing/documenting. That doesn't necessarily mean
| that the companies were poorly run - larger enterprises
| with more projects, teams and customers are going to
| require more meetings.
|
| Maybe he worked at poorly managed companies, who knows. The
| fact that he was asked to participate in meetings instead
| of only being assigned purely code-related tasks isn't very
| compelling evidence of a company being a "joke".
| pydry wrote:
| I tend to find that where the PO/product job doesnt have
| to be shared with developers the velocity and quality of
| the product improves considerably.
|
| I dont think that relatively speaking companies that dont
| do this are horribly run since it seems to be the norm
| but I can see why somebody who isnt used to it would
| rant.
|
| In general larger companies do everything inefficiently.
| It's to be expected. Small companies wouldnt exist
| otherwise.
| malort wrote:
| > the author's complaint that he doesn't get to spend
| 100% of his workday coding/testing/documenting
|
| The author's complaint was that he only gets to spend
| 12-25% of his time on these tasks on a good day.
| MrBuddyCasino wrote:
| > The author seems like someone who just loves writing code as
| opposed to wanting to deliver maximum business value (As
| defined by the company), so it makes sense he dislikes big
| companies.
|
| I think the point is that very little actual business value is
| being created. This not necessarily due to "actual business
| needs" but because of deterioration of culture over time and
| the inevitable principal-agent induced issue of managerial
| bloat.
|
| Instead of accepting that increased communication needs will
| slow down everything to a crawl, how about eliminating needless
| communication? Thats how Amazon does it, and look where they
| are now.
| sanderjd wrote:
| It's always a worthy goal to try to improve communication
| efficiency, but it's also the case that a very common failure
| mode that programmers at the leaves of org charts do not
| understand what is driving the value of the business they're
| working in, and have an inflated sense of the importance of
| the code they're writing (or that they wish they were
| writing).
| MrBuddyCasino wrote:
| Yes engineers can be at least as ignorant as the "MBA
| business types" they like to scoff at. I haven't seen that
| in a _good_ engineer though.
| sanderjd wrote:
| Oh I have! It is pretty much universal in _young_
| engineers, many of whom are eventually great.
| drewcoo wrote:
| > it's also the case that a very common failure mode that
| programmers at the leaves of org charts do not understand
| what is driving the value of the business they're working
| in
|
| If that's common and not being addressed, it must not be
| important. If it's not important, why mention it? Seems
| like victim-blaming.
| BlargMcLarg wrote:
| But that goes for everyone, until you can put it into
| numbers which aren't gamed. That's what is being challenged
| here. Do the communication methods as they exist today
| provide value, and to what degree? Do we have actual
| numbers?
|
| Whenever the "we hate meetings / the current bureaucracy"
| crowd criticizes the current state of affairs, the
| opposition tends to seek the high ground and go "well but
| you just _don 't understand_ what drives value". Meanwhile,
| there is a surprising lack of numbers regarding all this.
| sanderjd wrote:
| Ironically, trying to measure this better would
| inevitably require more bureaucracy! It's a good point
| nonetheless.
|
| But I'll also say a positive word for qualitative
| reasoning based on experience being a good first
| approximation of things. If something gets pushback from
| a lot of people who have spent a lot of time trying to
| coordinate large efforts, then it's worth considering
| that those people may be right. I don't know anyone who
| has spent a lot of time in one of these coordinating
| roles who thinks that the primary issue is too many
| meetings and not enough code being written.
| BlargMcLarg wrote:
| >If something gets pushback from a lot of people who have
| spent a lot of time trying to coordinate large efforts,
| then it's worth considering that those people may be
| right.
|
| It's one thing to consider it an approximation, it's
| another thing entirely to consider them "right" which is
| frequently followed with "so we won't investigate any
| further". Most of us don't live in situations where such
| decisions are actually critical. We can afford to
| criticize and experiment. Instead, this line of reasoning
| tends to be misused and shush any investigation.
|
| >I don't know anyone who has spent a lot of time in one
| of these coordinating roles who thinks that the primary
| issue is too many meetings and not enough code being
| written.
|
| And you don't think that group, much like others, may be
| a _little_ self-reinforcing?
| sanderjd wrote:
| It isn't "so we won't investigate any further", it is "we
| don't think it is the best use of our resources to
| investigate this" and in my view it also implies "but if
| you have a good idea for how to investigate it
| empirically, please feel free to do so".
|
| I don't think "that group" is self-reinforcing at all.
| Essentially everyone who comes in with no experience
| comes in thinking "meetings are crap, communication is
| crap, we just need to write code". Most of those people
| (but not all!) slowly but surely change their minds as
| they gain experience. But every one of those people is an
| opportunity for the thesis to be disproven. Similarly,
| nearly every new organization is an opportunity to try
| something new. Google didn't start out with lots of
| meetings and engineering committees and design review
| processes. They started out just wanting to write tons of
| code. They didn't hire management (or "agile")
| consultants or bring in outside managers as they grew to
| come tell them how to behave like a big company is
| supposed to. The people who started out writing all that
| code and ridiculing bureaucracy are the same people who
| eventually accrued processes to manage meteoric growth.
|
| I really don't think people are as narrow-minded and
| closed off to this as you seem to believe. People are
| hungry for a better way to manage organization growth,
| it's just a high bar because people have seen lots of
| these kinds of efforts, and frankly just get kind of
| bored of chasing "one weird trick to make everyone way
| more productive" again and again.
| ZephyrBlu wrote:
| "very little business value" is highly subjective. I'm sure
| that Amazon also has a lot of activities which generate "very
| little business value" under whatever measure you define.
___________________________________________________________________
(page generated 2022-05-16 23:02 UTC)