Ask HN: Do you hate software engineering but love programming?
I have come to a realization that I don't really enjoy Software Engineering(& the processes that it comes with) but I do love programming & solving problems.
Finding and fixing bugs is a lot of fun. Incidence response is a lot of fun. Hacking on new projects is a lot of fun. Writing unit tests is fun too.
Refactoring, rewriting, sprint, agile, rearchitecting things etc aren't that fun. I like a few languages and I am not too keen on learning new paradigms or languages unless I have to. I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get out.
What are some good jobs for a person like this?
732 comments
[ 4.8 ms ] story [ 371 ms ] threadA programmer is a person who writes program code.
A software engineer applies engineering principles when designing and/or implementing programs.
A computer scientist uses scientific methods and rigor when solving problems relating to computing.
Corporate work has a bad reputation but lots of upsides. I work in a small team of 5 people on a system that has about 40 users. Its amazingly better when you can talk to everyone, know what all the users want, dont have to worry about constant uptime or scalability. Flexibility and budget to pay for good platforms. Just dont talk about the refactoring - rewrite from scratch!
Reply: Yes it is expensive, the users are all paid more than us though which means we're helping them be productive. I have to add we also own a second application that has about 100 users that we spend some time on maintenance and support.
Gosh, that is expensive software!
Anyone who produces direct output to a small group of people is expensive in a similar way.
Some applications (control systems, etc.) have no users the traditional sense.
Internal tools used by a dozen or a couple dozen AI engineers/Data Scientists, the models they output used by millions. It's totally worth keeping 5-10 person engineering team to create better and stronger tools that make upgrading and deploying new models easier and faster
I've worked in AI/ML for a long time, and I can tell you that in all but the rarest of exceptions nobody has sat down and done the math to really determine if that value is there. In my experience, most cases it's not.
I've seen teams like you describe and then asked them "what's the difference in value between what our model does today and the theoretical optimum"? The answer, which nobody liked, was fractions of a penny per user. That means if the team achieved perfection it wouldn't really matter in practice.
We're going to see a lot of the AI/ML teams disappear as companies are forced to focus on determining the real value add being provided.
To tie that back to your comment -- imagine its for a team of 40 users but the company would ideally like them to be a team of 400 users. Yet because of the software being created, those 40 people are doing the work of 400.
You can extend that line of thinking pretty far -- and going down that line of thought is when I realized how valuable programming is. When you build the right things you are literally creating value with everything you ship, and it adds up over time.
Definitely. A cheap computer can outperform a billion humans at certain types of tasks. One must merely find the right tasks for the computer in order to exact unfathomable value. AI is going to expand the problem domains that computers can compete in by several orders of magnitude. The era of SPUs (Single Person Unicorn) companies is near.
I mean the extreme case is a developer writing scripts they only use themselves, which would be a 1:1 ratio.
I can almost guarantee that you’re just at the wrong company.
Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings, and joint work across a big number of “stakeholders”. These companies will take the joy and productivity out of programming and replace it with a series of rituals and set of language that people use to go through the motions every week so they can collect paychecks.
Start interviewing around. Talk to your network. Find a company that values programming and real productivity but discourages unnecessary meetings and process. You will be much happier. There is no escaping the fact that you’ll have to work on legacy code, document your work, and meet with people some times. However, it doesn’t have to be a miserable process-filled slog.
Because it’s a statement about men or because of the implied possibility they could be unhappy in their marriage?
Also, why is it horrible?
It appears this world has become manically trigger-happy to label something as -ist or -istic, when it contains even only a hint of something someone could possibly understand the wrong way.
It would be curious to examine in a psychological study if this reinforced behavior has developed more due to a subtle social reward system for the “labelers”, or due to a punishment system for the “non-labelers”.
That is wildly untrue. The research on whether men or women are more satisfied in their marriages shows that they have about the same levels of satisfaction.
For example: https://onlinelibrary.wiley.com/doi/10.1111/jomf.12077
Not really sure why the demographics of philosophers effects the impact of the statement. Most philosophers are white, would it have been more impactful if the statement had brought race into it?
But there are less aggressive ways to say it.
If we are counting only heterosexual and 2 people marriages, wouldn't the number of people stuck in unhappy marriages be exactly 50% men and 50% women?
At any rate, it reminds me of the classic physics joke:
> An experimental physicist comes running excitedly to a theorist's office, waving a graph taken off his latest experiment. "Hmmm", says the theorist, "that's exactly where you'd expect to see that peak. Here is the reason." A long logical explanation follows. In the middle of it, the experimentalist says "Wait a minute", studies the chart for a second and says "Oops, this is upside down." He fixes it. "Hmmm," says the theorist, "you'd expect to see a dip in exactly that position. Here is the reason..."
"Those happily married make great partners, while those unhappily married make great philosophers!"
is any less colorful than the original.
The original statement will be read by men and some men will connect to it right away, because rather than envision some abstract person, they are made to immediately picture a man, and in that image they may recognize themselves, like looking at a mirror.
Sorry, are you saying that the audience of the statement is on purpose only men? If so, how could you possibly support any claim that it's not misogynistic?
In isolation, it is innocuous, and has the caveat emptor. Though, if you get slapped with, you can't be a great philosopher (for what are happily or unhappily married women other than just spouses), you can't be police, fire fighter, coder, CEO.. it's just another slap in a series if many that occur daily. So, the idea is stop with the isolated examples, and perhaps the bombardment will lessen
Isn't it?
Wasn't Socrates replying to a question from a young man when he (allegedly) said that?
Since the origin of that quote is directly in response to a man, isn't it aimed at ... men?
[1] https://www.quora.com/Did-Socrates-really-say-if-you-get-a-b...
I don't "tones" have anything to do with it; in the 80s, Law, Accounting and Medicine[1] was absolutely dominated by men. If you think that introverted nerds are sexist, they have nothing on how doctors, lawyers and accountants were, nor how sexist the purchasers of those services were (often assuming that the men would be more competent).
And yet, today those professions have as many (if not more) females than males.
It's a stretch to think that general tone of an industry was responsible for females leaving the profession filled with introverted IT nerds and moving to high-powered and high-status executive professions.
[1] Other than nurses, in which men are still only a rounding error.
The industry has plenty of attractive qualities for any sex: Good money, good jobs. These far outweigh the occasional toxic male who is easily put down these days. If women aren’t signing up, then maybe they just don’t care about computers as badly as people want them to.
But sure, if the metric you're optimizing is raw views and smiles and laughs, then probably the way to go is leaning into stereotypes. There's a reason those views and smiles and laughs are called "cheap".
It's just like changing our default branches from master to main, honestly probably not a huge deal to any rationale person, but the cost is negligible so why not?
It's possible to be empathetic and considerate, making minor adjustments (and also not judging those who innocently don't) without being the "woke" police!
It is totally not.
As Ricky Gervais put it beautifully, like it or not, if you categorize the people of the past with the standards of today, you are preparing the people of the (near) future to categorize you about what you say today.
Now imagine that people think of Aristotle as a misogynist, like if it is actually important, he died 2,300 years ago after all and nobody studies Aristotle because "and now let's read about that guy who hated women, because it's something important to learn: women are trash", but
By the 1930s, a new kind of human zoo appeared in America, nude shows masquerading as education. These included the Zoro Garden Nudist Colony at the Pacific International Exposition in San Diego, California (1935–36) and the Sally Rand Nude Ranch at the Golden Gate International Exposition in San Francisco (1939). The former was supposedly a real nudist colony, which used hired performers instead of actual nudists. The latter featured nude women performing in western attire. The Golden Gate fair also featured a "Greenwich Village" show, described in the Official Guide Book as "Model artists' colony and revue theatre."
Or this
https://en.wikipedia.org/wiki/Human_zoo#/media/File:African_...
Sorry if I stand with Aristotle, despite him being a man of his times, and not with 20th century human zoo.
edit: to put it simply, should we talk to German people or everytime they try to say something we should shut them up reminding them that they did the holocaust?
When I disagree with someone from the US, can I use "you are the only people in history to have dropped two atomic bombs on civilians, you are wrong by design!"?
Why Aristotle is problematic, but nobody says "he was a Trump but a lot more intelligent than Trump and actually, now that I think about it, he never said <<grab them by the pussy>>, so Aristotle was less misogynist than Trump"?
Aristotle has never been POTUS.
I understand pushing society forward, so why blame people who have died thousands of years ago for things they are not responsible of today?
Does someone really think that quoting that sentence from Aristotle will plant the seed of misogyny in people's mind?
Is this really the kind of trust we have in each other's intelligence?
I believe people can read the context loud and clear.
Yes. https://en.wikipedia.org/wiki/Aristotle%27s_views_on_women
> Among women's differences from men were that they were, in his view, more impulsive, more compassionate, more complaining, and more deceptive. He gave the same weight to women's happiness as to men's, and in his Rhetoric stated that society could not be happy unless women were happy too.
And the modern psychology:
https://www.bbc.com/future/article/20161011-do-men-and-women...
I think you’re really stretching the word “misogyny” when you’re using it for people who accurately describe reality and view male and female well-being as equally important for society.
> Aristotle saw women as subject to men, but as higher than slaves, and lacking authority; he believed the husband should exert political rule over the wife.
Your post is more misleading than mine: you’re hanging your entire opinion on a de-contextualized cherry-picked line and using that to ignore other parts of the philosopher’s work.
Go on, scream about how everyone who disagrees with you is an istaphobe — nobody cares.
I did not make the rules.
Yep
> In his work Politics (1254b13–14), Aristotle states "as regards the sexes, the male is by nature superior and the female inferior, the male ruler and the female subject".
> While Aristotle reduced women's roles in society, and promoted the idea that women should receive less food and nourishment than males, he also criticised the results: a woman, he thought, was then more compassionate, more opinionated, more apt to scold and to strike. He stated that women are more prone to despondency, more void of shame or self-respect, more false of speech, more deceptive, and of having a better memory.
_________
> apparently nobody has ever read the great philosophers.
Yep
I can tell, because I've made posts like this before, and I always regretted it later. Have your angry argument in a journal or text file (Lately I've really liked Markdown with source control). Then revisit it later, and add in the side you're arguing against. Then revise it so that you're actually making a clear point, and remove all the personal insults. Then post it here, because I want to read it. But until then, I have no idea WTF you're on about or why you're so defensive of a very-long-dead philosopher.
edit: welp it's flagged now but they straight up called another poster "stupid."
The source of unhappiness for women seems to be the reverse. A husband that’s not doing all the things she nags about automatically.
I think priorities are just fundamentally different somehow.
Yes it does.
Did it do it right?
doesnt sound like any -ism to me
Nowhere it is implied that an unhappy marriage for a men is due to women in the marriage, if I had to guess, unhappiness in marriage for men is tied to having kids.
Anyway, focusing on the fact that it says "men" instead of focusing on the fact that it says "unhappiness" says a lot about the priorities people have nowadays.
It's like reading "The Fox and the Grapes" and focusing on the fact that there's a talking fox trying to eat grapes.
Had that been said in person, even with someone we only recently met, we’d have “known” what it was meant to mean and that it was just a figure of speech to support their main point. Online, people will read every word selected and choose to vilify you for using a pronoun or some other random extreme literal take on your word choices without really considering what your intent or meaning or that you is (often there’s not much, it just happens to be the choice of words they made while typing on a tiny device and trying to be concise). It’s also not considered that online we’re intermixing generationally, culturally, economically, and so many ways. When a 50 year old person says something like the word “retarded” it may feel normal and they are ignorant of the fact that anyone under ~30 knows not to even say that word, it’s the “r” word. Then you have the other “n” word that everyone knows is unspoken except it’s found and heard everywhere because some people can and do say it steadily.
As an example, I frequent a local subreddit for my city. Something that regularly comes up is crime and homeless and such. If you have anything to post there. Someone else will invariably reply with yes but redlining, Jim Crowe, disenfranchised citizens, etc. Those are all base general knowledge and historical facts for sure. I think everyone is well aware of them. But, it’s difficult to have any discourse when the audience expects a full historical account of why the situation exists before solutions can be discussed. It’s pretty tiring and I’ve basically stopped chiming in on those kinds of things.
TLDR: communication is hard and text only is really hard.
Also to label something as maniacal, perhaps.
So now you can't make a quip about wives unless you also make a quip about husbands (or else generalize it to "persons") though even these are now too restrictive for some. Heaven help you if you dare observe that there are differences between men and women, complementary differences no less, that lead to humorous tensions between them and peculiarities particular to each that surface within their shared lives.
Shall we raise a toast to ourselves, savaged men (and women!)? Humor is dead. And we have killed it.
Welcome to Western society, you're privileged and you should be guilty and ashamed.
How did we get here?
The expression "privilege" itself makes people feel attacked and get defensive. If you say the same exact sentence replacing "privilege" for the definition and it greatly changes how people react to what you say
I think there is probably a happy medium of wokeness that can be reached via measured discussion between respectful adults. I think in real life (at least in my experience) people are willing to have those discussions, and are much less polarized and divisive than the internet/cancel culture might have you believe.
> It would be curious to examine in a psychological study if this reinforced behavior has developed more due to a subtle social reward system for the “labelers”, or due to a punishment system for the “non-labelers”.
This is intriguing by the way.
It's not; it's the result of a vocal and aggressive mob - people are taking care to not draw the attention of the mob.
You can say "it's just a saying, it would be equally true with the roles reversed" -- but then, why aren't they?
Sure, on the misogyny scale, it's pretty mild, but sayings like this that implicitly reinforce the male-centered world we live in are in some ways the most insidious.
The mature way to approach the problem is to work together to resolve the issues -- or if that isn't possible, terminate the relationship. You can't just make yourself the victim and say it's all the other's fault.
Additionally, consider that you are the one bringing the nagging wife trope into this: it's merely one of many possibile explanations and unhappy marriage.
Saying "I was in an unhappy marriage and it made me a great philosopher" would be fine. It's the generalization which is an issue here.
1. Can only be married to a woman, sometimes a pre-arranged woman
2. Has religious or cultural norms keeping it that way
3. Improving the marriage is the woman’s territory
This is probably a realistic aphorism for a larger group of people than those who can call it misogynistic.
To understand it better it is worth noting that it is a bastardization of this misquote commonly attributed to Socrates: “By all means marry; if you get a good wife, you’ll become happy; if you get a bad one, you’ll become a philosopher.”
As detailed in this ( https://qr.ae/pvP31C ) answer on Quora, Socrates never said (or was never recorded to say it, he didn't write down his philosophy) this exact thing. But there is a recorded dialogue that is plausible as the source of the simplified quote.
While less clear from what kraig911 said or from the original dialogue, the commonly spread (meme) version of the quote, which I pasted above, makes the misogynism clear. I hope further explaining that is not necessary.
It is important to note that Ancient Grece was very gender unequal, so a misogynistic quote in that social context is not something surprising, even for one of the brightest minds. That is just how society was in those times, and those philosophers did not get the benefit of hindsight we have today.
Besides, as stated above, Socrates didn't actually say that misquote. He was commenting about the challenges of his relationship with his wife. From that dialogue, it is even implied it was a conscious decision he made.
The misquote is especially dreadful because it is a generalization over the entire feminine gender. I am now quite curious when exactly in history did the misquote take its commonly known form.
I am quite surprised that of all the people commenting, no one attempted to go to the source of that meme. Instead, everyone just espoused their viewpoint. I wish HN to be a place of knowledge seeking, not a place of culture war.
Edit: looking into this a little deeper, Spencer McDaniel, the one who wrote the Quora answer linked above, has an entire blog about ancient times and expands on the issue of misquotes: http://talesoftimesforgotten.com/2019/07/16/fake-and-misattr...
All that stuff you hate isnt unique to software. It's just capitalism.
Each department's revenue goes into a shared pool, which is distributed amongst the company in annual planning cycles by an unelected board of representatives. Who gets what is as much a function of meritocratic principles like department revenue as it is of who happens to have senior leadership's ear that year (how many times have executives been convinced X is the future, we need more X, with no concrete performance to back that up?).
There are some larger, more sophisticated companies that break this mold, but more the exception than the rule, I think.
All of that isn't actual agile. It's Fauxgile and has nothing to do with what agile is about, which is about removing impediments to productivity, removing meetings (why were there standups? Because they shouldn't exist in the first place, and if you absolutely positively can't avoid them then at least make them as short as possible by making everyone as uncomfortable as they should be) and laser-focusing on actual productivity.
> (If agile is done well though it can be amazing but that's another topic to me)
Yes. I would phrase it as: if agile is actually done.
Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value. But they aren't "the thing" about Agile. Not even close.
Constant reflection and drive towards faster feedback. XP or if I squint Scrum can be a starting point, but you gotta adapt to the individuals on the team and the characteristics of the type of problem you are solving.
[0] https://agilemanifesto.org/principles.html
So really, you're never "doing Agile". You're "doing $X" where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or whatever. At most companies what you get, in my experience, is a bastardized version of Scrum cobbled together by somebody who has never actually developed software, took a couple of Scrum classes (maybe), paid too much money for some "help" from some "Agile coaches", and is hoping some of the resulting shit will stick to the wall.
FWIW, I've actually had the pleasure of working at company that did Scrum and really did it well, and it was honestly a great experience. Actual Scrum, as documented in the Scrum Guide, isn't bad. The problem is when people take base Scrum and start tacking on additional shit (see: "agile coaches" and "agile consultants") and wind up with a bureaucratic / kafka-esque tarpit of interminable meetings, ceremonies, and artifacts. In other words, pretty much exactly what the Agile Manifesto stood against in the first place.
Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.
Read the Agile Manifesto. That’s what Agile is. All else is either: - (good) trying to implement the Agile Manifesto, or - (bad) trying to make current process appear like Agile.
Just stick to the principles of focusing on the product customer value over the processes themselves, with recurring reflection over how your process is working, as per the agile manifesto.
If your company hasn't done this before, Scrum is a good starting point, but it is by no means a goal nor the final destination. This is where most companies fail.
I did leave and the company did crumble shortly afterwards. The main reason wasn’t related to processes, though. It was already too late when the faux-agile was introduced.
https://scrumguides.org/scrum-guide.html
Ctrl+F "JIRA" - 0 results
Ctrl+F "velocity" - 0 results
Ctrl+F "on-call" - 0 results
Ctrl+F "manager" - 0 results
Selected quotes:
> Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
> During the Sprint: No changes are made that would endanger the Sprint Goal;
> The Daily Scrum is a 15-minute event
A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.)
At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more.
At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time.
The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take.
Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.
Spot on. You and parent have hit the two points that matter:
1. Agile is about removing impediments to productivity
2. velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc are all, in some way, impediments to productivity (even if they do have some value).
I think the real reason you cannot have real agile is because businesses don't run in a way that is compatible with agile, so over time all processes within a business will evolve to match how the business itself functions.
Except it's not even really about productivity, it's about outcomes. The productivity is only important insofar as it achieves the outcomes. The ideal agile process would have the team on the golf course or in the spa but still changing the world (any suggestions on achieving this, gratefully accepted, as always).
Sadly, I think you are correct. It's very hard, at best, to make "the business" operate in a way that's truly compatible with the agile approach on the tech side. :-(
I won't say it's impossible, but it's definitely not easy.
For me the value in Agile is what we end up NOT doing - we never get to that shit because in the end it's not that important. So we never waste time doing it.
Agile was the best of times, Agile was the worst of times, Agile was the age of wisdom, Agile was the age of foolishness, Agile was the epoch of belief, Agile was the epoch of incredulity, Agile was the season of light, Agile was the season of darkness, Agile was the spring of hope, Agile was the winter of despair. -- Paraphrasing Charles Dickens
Which country implements pure capitalism? What would that even look like? 0 tax? having to pay private police companies? ....
Some of the principles are actively harmful, like welcoming changing requirements late in the process.
"Individuals and interactions over processes and tools"
OK, not terrible, but why not "interactions and tools over individuals and processes"? De-emphasize individual's egos and ritualized processes, focus on the things that get work done and communication between entities.
"Working software over comprehensive documentation"
Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.
"Customer collaboration over contract negotiation"
Fine. You'll still need a contract, but it's definitely important have a collaborative rather than adversarial relationship with customers.
"Responding to change over following a plan"
Tends to make sense when gathering requirements, turns into a horrible idea later on in a project. Also fails utterly when working with something like a factory (making a hardware product with embedded software). If your entire view of software is web apps, this one seems like a good idea. If you're making something with a manufacturing deadline, it's a recipe for disaster.
This means something a little different. It wasn't talking about "end-user" documentation. Rather, it meant "product specifications." Do you need to design the system upfront in UML before you start writing code? You may still need something like a whiteboard sketch or something similar, but that wouldn't be "comprehensive."
The distinction is more about how granular you need things. Do you need to negotiate every piece of business-logic and get signoffs on mockups up-front, and in the case of paying customer, rather than internal stakeholder potentially including placing them into a legal SOW? Or can you just agree to a bullet-list of high level functionality, and then establish a working arrangement to receive feedback and refinement. Build and MVP and get some use, then make it better. Likely the initial understanding of the requirements was flawed anyway, so being reactive to the change, with buy-in from the customer will be a better plan for success. But yeah, this might not work with physical products.
> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.
Another problem:
It makes onboarding new engineers difficult. Without any documentation on what each API endpoint does, or the purpose of every repo, getting an understanding of how the system works ends up requiring scanning through code manually or taking a lot of time from other engineers asking questions.
It's especially bad when microservices are given non-descriptive names like Galactus or Omega Star.
The point is that documentation by itself doesn't deliver any value, and there are diminishing returns with amount and detail level of documentation.
Agile doesn't say you shouldn't document, it says you shouldn't spend more time documenting your API endpoints than Implementing them.
You can get there with a big document for a program that doesn't work
You can't get anywhere with a program that works and no document. You might get sales, but that's someone else's job
I certainly would have preferred just a big document instead of the code I was given on my current role
So that’s the why. You can ask for elaboration, or disagree with the results, but the opinion of the signers of the Agile Manifesto, based on their experience, is that to prefer the former over the latter, while acknowledging that the latter principles have value, they tend to succeed (and enjoy their work more) when deciding between the two (there are always trade offs) to give greater weight to the more lightweight, practical, and less rigid values — hence the use of the word “agile”.
TLDR: Businesses purchase development effort in terms of contracts, and the contract is almost always "You will deliver $X for $Y amount, in $Z months or less". Agile is the opposite of that as far as business is concerned - "We will pay $A per hour until our money runs out or we are satisfied with what we get".
I've never understood this one, to be honest. Business runs on contracts; in any interaction with the outside world (suppliers, customers, employees, etc) the businesses contract is what makes or breaks that interaction.
In 999 out of 1000 cases, no contract == no interaction.
I mean, look at it this way: when you ask a crew to paint your house, you specify the colors upfront. You don't iterate with them on after every room, or every wall.
You certainly will not engage with any crew who wants to paint your house using the guidance of the Agile Manifesto, because then you'd have little to no upfront indication of the cost, you might have a house not gully painted (because you're paying per hour for their time, and once your money runs out they stop working).
Agile works great for teams internal to the business - the money never runs out unless the business shuts down. But for external developers, the business cannot engage without a contract, and that contract will be "You will deliver $X for $Y in $Z months", and not "We will pay you $A hourly until we are satisfied with the result".
The practical result is that the agile way and the business way are entirely opposites of each other. This explains why dev teams within companies constantly complain "This isn't Agile!" ... because business is trying to enforce some sort of "Deliver $X within $Z months" and the agile team is working with "We'll collaborate until the stakeholders are satisfied"
Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.
In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.
The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.
> In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.
Doesn't matter - the people paying for the software are not the ones that are going to be using it, so showing it to them is pointless (they just want their bullet points/requirements checked off).
Showing the software to the users is equally pointless, because they don't have the authority to request changes (any change is a bill that has to be approved).
See my other reply to you: https://news.ycombinator.com/threads?id=lelanthran#34381865
> The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.
Maybe, but unless you have an alternative that addresses the problems in not having contracts, there's little point in telling other people that they don't understand the problem.
"Oh, we hit our schedules and costs 100% of the time", she said.
I was incredulous, so I pressed her on the point.
"Well, compared to the contracted schedules and costs, we run 200% over on average by the time we deliver. But what happens is that customers quickly figure out that what they contracted for isn't anything like what they actually need. And every time a requirement changes, we add time and money. A lot of time and money. More than enough to make up for any actual overruns. So we always hit our schedules and costs exactly, by the time we're done."
In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.
...
> In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.
How is that a scam? "We will deliver $X in $Y months for $Z money" is easily predictable by the client when the client wants to change $X.
If the client doesn't change $X, the client can understand what they will pay and when they will get it.
When the client changes $X to $X+a, they still understand that delivery will be "$x+a in $Y+b months for $Z+c money". In fact, the original contract they signed made it clear to them what the cost and time was for changing requirements.
More to the point, when they want to make a change, they can balance the need for the change against the cost and time. Even better, because they know these things upfront, someone at the client will have to approve the cost and delivery time for the new requirements. That person is not going to give the supplier a blank cheque.
It's a good deal better than "We deliver working parts until you are satisfied or until you run out of money. We cannot tell you in advance how much this will cost and how long it will take."
I mean, if experienced developers are unable to get their software development supplier to deliver with only a small margin of money/time overruns, what hops is there for the procurement person at any company?
Since external customers and non-swe stakeholders expect binding contracts and even waterfall, I would consider it essential to learn how to interface agile processes with the said contract-driven stakeholders. Telling them that we are trying our best just doesn’t work.
What's the alternative? Never have contracted-for software? Only accept contractors who are prepared to do Agile?
How does the procurer then put out bids, without having requirements up front?
How do they evaluate bids from various suppliers without knowing what the final bill is? How do they shortlist the three "best" bids with no costing information? How do they even know if they can afford it?
How are the suppliers supposed to submit bids without knowing what they are going to bill for?
How does audit make sure that the process was fair?
Once you start supplying/developing software for companies that are large enough to have a procurement department, you better believe that the process all runs on paper[1].
[1] Or the digital equivalent.
This isn't a useful analogy - more often, it's like asking a crew how much it would cost and how long it would take to paint your house, except the house isn't built yet, you're not sure what you're going to use it for (or whether you'll actually use it as a house rather than a B&B), plus you reserve the right to change colors at any point in the process.
This was written in a time when documentation/spec was often written before the software, without taking into account the difficulties of implementing it.
Agile seems to imply that software comes before documentation in terms of priorities.
A lot of the points in the manifesto turn out to be slightly redundant. Comprehensive documentation, as entered into a tool, is wasted time when what you need to do is spend time with the customer developing their ideas into good software.
“Fauxagile” *is* agile, because thats what the majority of places in reality do.
“Agile” needs a complete rebrand.
Who gets to do things that they have experience in all the time? Not me at lest. And what manual do you read ? There's almost never anyone who understands it all quite apart from having written "a manual".
I've found that in many cases, that generally makes return on investment hard to keep track of, and I think that most companies want profit. Balance is the key though and balancing what you describe as bad with fast shipping, I think is the best of both worlds
It’s just a buzzword for practices that people would be doing better otherwise without all the bureaucracy. Pretty sure one of the original authors of the manifesto declared it dead too, but I’m not going to google it because honestly the agile manifesto is not a religious text to me and I think the whole industry grew out of a single fairly common sense idea that got utterly co-opted by snake oil salesmen.
Like DevOps.
And all of these people are completely gated off from interacting with the people actually building applications by a byzantine process involving ServiceNow tickets, MS Teams messages, eldritch incantations to Elder gods, ritual sacrifices, and the phrase "The goat doesn't need to be very big, but it does need to be alive."
Cthulhu is a lot easier to please.
I don't think you're wrong, but I should point out that Agile started out as a rebellion against "meetings, rituals, and meta-work and not actual productivity". As somebody who got involved in one of the Agile tributaries before the term "Agile" was coined, I'd say the actual problem is older and deeper.
I look forward to another rebellion, but would-be revolutionaries should make sure they don't fall into the same trap, or you too will see your new terms and bold ideas corrupted to the point of meaninglessness.
On top of that, like most popular languages and technologies it isn't really good enough for people who care, but it's good enough for people who don't and also happens to please "biz" people.
Agile was created to beat exactly those things that you are mentioning. Then Agile became big, enterprise became aware of it and smothered it with their rituals, processes and bureaucracy. And now we're back where we started again.
I'm not sure I understand what this means, can someone clarify for me?
https://news.ycombinator.com/item?id=34380697
Explaining the meaning of a bad meme is not interesting but if you are still asking what it is supposed to mean then here goes:
The first half is obvious because it is a tautology. It states that "An X is an X."
The second half implies that unhappiness pushes one to become a philosopher because they start thinking about how they became unhappy. Why? Who knows. Most unhappy people do not become philosophers, but some might. Also, not all philosophers are unhappy. Also, gender and being married or not have nothing to do with becoming a philosopher.
You are correct that it's confusing why the implication should go without saying. It's because it doesn't. It's a simplified rewording and further generalization of a misattributed misquote meme that is itself a generalization and mischaracterization of a dialogue line of a philosopher describing his own situation and his own choices.
As for why happiness is less productive then unhappiness, there is this gem of an explainer: https://www.youtube.com/watch?v=yWkq7btSQvs
I see, thank you for the explanation.
That's definitely not how I view philosophy or the motivations of those who think deeply about such things, hence my confusion.
Waterfall had its own endless set of meetings and downsides. I'm not sure agile changed that at all in the large, regardless of how "well" agile was implemented. Some teams did have project management that "shielded" teams, but that can happen under agile too, depending upon how it is structured.
Even if this is true (which it most likely is), there's no guarantee the company you move to (in your quest of finding "the right company") won't either a) also be the wrong company again right off the bat or b) become the wrong company again.
I've kind of just given up. I've accepted I'm basically a "technical plumber". Take data from this system/vendor in this format, convert it to another, make low six figures, have benefits, try to focus on life outside of work.
The interviews went amazing, everything was Star Trek utopian future amazing, it was like the fantasy I had about where I wanted to work had manifested. I got a job offer, and took it immediately.
The first day of work, no one on my team was there to let me in, so I hung out in the lobby for several hours waiting for anyone brave enough to get me to the badge people so I could open the door on my own. By five months in, I'd not had a manager check in yet, no one on the team would talk to me, and I realized I was a professional bench warmer. I'd been bamboozled, body-snatched from my boring, process-jammed, low-progress IT job.
Fortunately the fortune 100 took me back. I hadn't burned any bridges on my way out, and my seat was still warm. My cube was still there, my gear all waiting for me to just log right back in 6 months later like I was simply on a long break.
Three years later I'm still here. I'm terrified to go looking again cause I can't have my heart broken twice so soon. I have no idea how to interview well enough to detect a trap. I think my age has a lot to do with it (I'm in my mid 40s and I average about 7 years per company so I don't experiment a lot with this).
I think that your strategy is the same as mine and that you should be rewarded for sticking with it, because there's success in it even if you're not constantly being entertained by solving the big interesting problems. Running a little personal infrastructure to learn the next big platform/language/thing is always a great hobby for people who can do a little more work outside of work, and just having interests that don't earn you anything at all are the most rewarding for finding brief moments of happiness.
There's "innocent sounding" explanation for the managers decision to cut the interview, but they're all tainted with some form of ageism.
"Oh the tech was textbook perfect but I didn't like that nobody wanted to stand around and bullshit all day"
Like bruh.
That office needed to be full. We'd hire guys who could barely spell HTML. The next round was $20 million or so. More hiring. It was like monkeys banging on keyboards. There were no code reviews, no process, nothing like that. We hired some of the most clueless management you could possibly imagine.
The product itself was half baked and ill-conceived. But we just kept on hiring. Eventually 2001 came and there were mass layoffs. I was not among them, but I left on my own about a year later. Eventually there was a fire sale and everything was sold for pennies on the dollar.
Did you consider asking someone going in or out to help you get a badge or to put you into contact with the right person?
Sounds like you passively waited for someone to come and help you, which might be fine for a short while, but eventually it's better to take action.
I've never heard of a "professional bench warmer" in software development. It's not as if devs get injured regularly and need replacements. Why do you think they'd hire you just to not give you anything to do?
I think this is real.
My friend who is serial Project Manager (he works for big corps here in Poland and changes job almost every year for last 15 years) actually uses the term "on bench" for programers that do not have projects assigned to them and he claims that he quite often hires people before project is confirmed, so from time to time some people are left hanging without free chairs when music stops.
I never changed job (Unusually work 2-4 years at one company) where I didn't have everything ready on my first day.
Or it could be pure chaos. Years ago I joined a startup that was scaling rapidly. The interview process was exciting, the people seemed great, and the compensation was very appealing. So I go in on my first day, eager to get to work. After sitting in the lobby a while, I'm told that they aren't ready for me, and could I come back?
The next day I come in, and they again say they aren't ready, they're very very sorry, and that I should come back tomorrow. So I do.
The third day I figure, great, now I'm going to get to work. But once again, nobody's ready for me. No desk, no computer, no nothing. They weakly suggest that maybe I could find a corner somewhere and read manuals?
I politely tell them that I think this isn't a match, GTFO, and never come back. They go out of business a few years later.
Quite useful time to spend learning.
My company likes to do the complete opposite. There is always endless work to do because we only hire if there's an immediate need for someone. The upside is that you're always going to be busy and lay offs are very rare. The downside is that we are perpetually understaffed.
I average about 2 years, and each company has been progressively better than the last.
Don't let a bad job hop stop you. To me it's the only way to really progress your career.
I've done a huge variety of projects, experienced a ton of different management styles, and of course also never stagnated compensation wise.
Leetcode kind of sucks, but it's possible to build up enough confidence to ace it.
Particularly start by focusing on one area until you see all the basic patterns. For me, I was rather weak with trees.
Job hoping seems to be the only reliable way to increase your comp. I was promoted at Intel and got 11% as a raise. Then I bounced and gained another 40%.
From there I doubled entirely. Please do consider your value, plus selfishly you'll help keep the software engineering market competitive if you do.
I think about my ancestors a lot, toiling in fields and fighting in horrific wars
We have it good, we really do
I've come to a sort of depressing realization, 30 years into this career: the kind of companies that _will hire me_ are usually not the "right" company. I'm not even a plucky bootcamp self-motivator, I'm a state-school CS grad who's never worked for Google, Facebook or Amazon. The hiring processes that don't filter me out are the sorts of employment processes that demand hour-by-hour status updates in the form of up-front-estimate timesheets and 24/7 on-call. Oh, well, I might actually make enough money to retire some day.
The grass is always brown — when there is any — and the septic tank stinks.
Product-focused companies also, in my experience, tend to put a lot more emphasis on ritual precision. Agile isn't just a means of organizing, it becomes the way you get things done. These companies also tend to have some culty vibes to them, but again, could just be my experience. At engineering focused companies I've "done Agile" but the emphasis was mainly on giving me tools, systems, and incentives to self-organize more than the rituals themselves. These kind of companies are actually where I learned to love testing a lot more than I used to, but that was because someone took the time to shape how I wrote code so that it was easy to test.
eg I like having tests, and I like writing them, because they make my life better. But the contrast between the effort level to write tests in ruby or python vs go... I hate go, I hate the lack of good mock support, and I dislike writing tests at work because I hate go.
I've had all of the ceremonies and no AC on plenty of tickets.
We had a new hire join a few years ago and every time they had a work task that they hadn't done before they'd make multiple meetings about their particular part of it, asking for advice in meetings instead of informal conversation, asking others to fill in documentation etc that might have been reasonable once or twice but essentially created a work by committee approach...to their work. It was exhausting and I let my manager know I was going to start declining their meetings semi regularly.
When people started declining the volume of such requests and tasks suddenly dropped.
But depending on how intractable your team or org, is, finding a new job may be easier.
Smallish companies often leave a lot more freedom for their developers, but you'll most likely also be missing a lot of things you've gotten used to (highly automated CI/CD, teams "responsible" for each part of the system etc)
Given that private companies with over $1B in revenue actually exist while examples of "[companies] that values programming and real productivity" are yet to be forthcoming, the parent post is using the metaphor correctly and the finance world is not.
As a perhaps incomplete or shoddy heuristic, smaller startups tend to focus on productivity and moving fast.
The correlation I see is big companies have processes that kill productivity, though I did work for a big company that was able to avoid it for a long time (new leadership did end up killing productivity right before I left).
And for what it’s worth there was no correlation with “agile”. I’ve seen good and bad agile.
The trick is finding a company that's not wrong.
Early-stage startups typically qualify, but they're also typically short-lived; they usually either go under or else grow into the same sort of "wrong company" one's trying to avoid.
A small business that's been around awhile, with a stable customer base and no ambitions for growth, is probably ideal - but good luck getting such a company to hire you. You might have better luck picking up multiple such companies as an independent consultant.
A different ideal (or so I've found) would be a company that's large but dysfunctional, or to be an "analyst" or somesuch in a department that's sufficiently large and autonomous to get away with having "shadow IT" (and a lax enough corporate IT department to not interfere).
* Small/medium size companies where you recognize most everyone even if you don't work with them. There are enough people so you don't have to do things you're not qualified for like in the very early days of a startup.
* Steady growth, but not crazy, venture fueled moonshots.
* Selling something that earns enough money to grow the business in a fairly organic way.
I worked in a place like that once and loved it, and did some of my best work there. I wasn't anxious that it would implode like a startup, and there wasn't much bureaucracy.
I think part of the problem that triggers this is in small companies, one engineer codes, a significant portion of the code base and has a strict vision in their mind about how that code should be structured. When new employees come in to bring new ideas, they become personally offended that their baby is no longer their baby. At large companies no one feels like they own 100% of the code, and each change is very collaborative.
Make sure you have solid metrics on your side to record problems with that microservice, document any delays caused my missing features, and eventually even non-technical management should get your point and start to apply pressure.
Usually management doesn't want to participate in these discussions, because they are more careful about retention (and stepping on toes). 1 engineer quitting is a 10% reduction in their workforce.
That's how you end up with endless process, design by committee, and having a dozen meetings with all "stakeholders" before actually writing any code.
I'd much rather work at a place where individuals or small groups have a strong vision on the code and product and are capable on executing independently on that. It sounds like the OP would too. But I understand it's a personal preference.
I guess that’s why large enterprises hate it, since they’re all about reducing risk.
If they get middling software every time then that’s preferable to the two extremes.
Isn't that dependent on whether you are the person guiding the code though?
Indeed. No company size is perfect. There are dysfunctions typical for small companies. There are dysfunctions typical for large ones.
But people have preferences; some things they can handle, other things drive them crazy. What drives you crazy may be different from what drives your friends crazy.
Perhaps everyone should try to work once in a large corporation, and once in a startup, to figure out their own preferences.
Or to be kinder. If you are filling your own hole (identified need) you can be more free in your approach. After all only you decide if it's right, finished, a failure or success.
What I vastly prefer is the 500-ish size. You can realistically at least know of every other developer (and find those you prefer working with and can learn with), there's more resources than just a 30 person company, and you're just not a tiny insignificant cog in the machine at a 100k mega corp.
We must have worked at very different places.
Everyone wants the problem solved, but how the problem is solved leads to frustration.
This happens extremely frequently and is in fact entirely normal.
Some types of businesses can do it more easily than others. Professional services can probably do it the easiest. A B2C business with a turnkey offering could have a lot of trouble paring back, especially if the product has a physical aspect.
But what if new opportunity is ok, gets you 30% more money, but your departure makes your current company very sad and perhaps worse place for everyone to work at?
I wouldn't expect a lot of support for the idea of staying if you ask the internet for an opinion.
When MBA culture took over in the 80s it became normal for companies to act like extraction machines. Employee loyalty crashed, with a corresponding increase in churn.
Taking investment money makes it hard to create a humane culture. But smaller private companies do at least have the option to consider it.
What did they change/do? If I may ask
- Paperwork - Extra managers - Lots of "stakeholder management"
Eventually, they tried to get us to integrate with more and more of their other products, which introduced a TON of extra "stakeholders" on every single project.
With every extra stakeholder they also had to introduce extra meetings and extra process until even making a small change felt like a massive chore. I went from merging dozens of changes a week to maybe one or two.
Felt pretty claustrophobic after a bit so I ended up leaving to go somewhere smaller.
> integrate with more and more of their other products, which introduced a TON of extra "stakeholders"
That scenario I hadn't heard about before. Good to know about that way for things to fail, too.
If you haven't seen:
"Excess management is costing the U.S. $3T per year (2016)" https://news.ycombinator.com/item?id=34290539
After 14 years in a workforce, my happiest moments were in software SMB (joined at 10 people and left at around 100).
Never felt like work. We were just building something cool together as a team on the same page.
Turned profitable after Series A and never raised again.
Later down the road I realised that these are the real unicorns once I actually landed in terrible jobs or corporates and how disengaged everyone is in the legacy organisations. Was genuinely shocked that these companies don't go out of business.
I am now trying to collate the list of companies which fit the criteria above but it's really hard.
I can almost guarantee your company needs less of the wrong people. You need them to leave. So, ahem, talk to your network.
What's an example of a company that values "programming" over the business?
However a company that values programming over managing will prosper more than a company that values managing more than programming. Just enough management that everybody knows they're working on the right thing is best for all (including the managers).
Process for its own sake (I'm looking particularly at cargo-culting "agile" astronauts) sucks the life out of everybody involved.
Even worse!
Also with "some software companies can turn even the simplest..." You may have forgotten to add "and add metrics to these rituals as performance goals"!
The folks in this other company just flat out said not worth it, just get your stuff done, ideal development scenarios and perfect harmony and alignment have too much hidden costs to bother with.
It's naturally a pro and con scenario but it was pretty refreshing to hear of folks so unconstrained by this self imposed constraint every other shop had imposed on themselves.
I feel like there is a golden middle where the team has decided on maybe 3 languages, one typed, one scripted, one cutting edge. And a few different deploy scenarios, and you can pick amongst them.
You're right that there is no promised land, but the quest to reach it prevents you regressing into hell.
You mean 95% of companies.
god - this is so true at my last company. Any attempts to decrease meetings, remove unnecessary process are met with heavy resistance. Getting shit done was nearly impossible. People had no responsibility for their work. Only wanted "stories" and "subtasks" assigned to them. Doesn't matter if the story was trash/useless/no-op, they just wanted it to pump their numbers because the quarter is ending. I shouldn't have tried so hard to make changes. They probably ended up getting reverted by the next person or manager.
Pro tip: if the company you joined tends to hire new people then retain them. Then fucking run. During the first "all hands" in that company, nearly 80% of people that worked in the organization were hired in the past 1 year or so. It ticked "red flags" at the time but I ignored it because honestly I needed the money at the time (just graduated college)
Almost every process these days is bought in by a new managerial hire, or after attending an event, where a talk or book that shows X companies that are very successful all followed the Y practice, and so 'we should too' as it's obviously the path to success. Rarely is there reflection on whether the process is working, and blame is laid at the feet of the workers.
Despite many recollections and experiences retold about how processes may not work, they are silenced by the advocates of such processes who will show how successful they were (and also just happen to make their living by advocating rather than actually being on the ground).
That said, as some have already mentioned, all of this is typically ruined somehow at nearly every company.
You're at the wrong company if you're unhappy regardless of the size.
I've worked at a very small company which was miserable because the owner didn't have a clue and was only interested in the bottom line to the point of letting the software and the systems atrophy.
I've worked at Megabank, and it was also miserable. Actually writing code probably ended up being a sum total of 3-4 hours a week. At best. Too many meetings. Absurd change control system. Crazy processes and sign off.
And then there have been a few mid-sized companies - 20-200, and they've been the most fun. Get on with coding and even whilst managing a small team.
I think there are parts of the process that people enjoy over others and that's based on many factors, personality, company culture, managers, coworkers, process and tooling, etc.
You don't have to enjoy every aspect of it. Just like enjoying cooking, and not enjoying doing the dishes.
The important part is being professional, doing what's asked, not being negative about it, and look for opportunities to improve that part of it.
In that case I suggest finding a commercially-backed, open source project which you are passionate about. You can have best of both worlds - plenty of bugs and community interaction, all while also making a living out of it.
Actually dealing with code is a pain in the ass. It's better than digging a ditch for ten hours a day but not really enjoyable for its own sake either.
The best functioning teams mix a set of people, with a diverse set of qualities, quirks, interests and disinterests.
And work to accommodate them all.
Unless you're an owner or a shareholder you're essentially a skilled laborer. Clock in, ply your trade, clock out. If they're jerking you around on hours get a better job or "quiet quit". Do things you like and feel fulfilled about in your free time, it's better to take joy and meaning in the society that you theoretically are working for the privilege of living in rather than looking for that satisfaction in your work.
A quote I often think about from an article titled Smart Guy Productivity--"Son, I don't go to a place called fun, I go to a place called work."
Speak for yourself. Lots of those things are fun. Sprint and agile have more to do with the workplace, sure. But refactoring, rewriting and rearchitecting things can be really fun. The first implementation of anything is going to be burdened by complexity and wrong assumptions. It's only on the second time through that you have clarity. The joy of having the solution work pales in comparison to knowing that the underlying code is a thing of beauty. Like a jacket with a beautiful lining, paying attention to the details that nobody sees makes your product inherently better.
> Finding and fixing bugs is a lot of fun.
Refactoring is a part of this process. Squashing bugs and edge cases is fun like playing whack-a-mole, but it's also fun to see the bugs and edge cases as a chance to question your assumptions, is this really a one-off, or could I prevent all bugs of this kind in some way?
after writing many features, adding the next one gets harder and complicated in my head, that's when I know that the code needs to be much cleaner so that adding the next feature becomes easy.
It often means that I delete code / completely skip a code base that went in the wrong direction and overcomplicated some part unnecesarily. And that's when my code gets much more elegant by achieving more and being simpler at the same time. I love it.
I love solving problems and fixing bugs. I LOVE optimization (when appropriate). But these are like 10% of what I'm paid for and I appreciate it can't all be the fun stuff.
Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved.
I’ve never understood people that just jump into coding without much of a plan - and I think the industry has shifted towards that a lot these past years. Everyone is used to learning by doing, and pretty much everyone seems to have an aversion towards reading and documenting. I feel I’m slowly becoming part of a minority.
I think this is a pretty common career progression. Coding can be fun and rewarding but I’ve written hundreds of thousands - possibly millions - of lines of code in a dozen languages and there is very little novelty left for me. The challenges of team organization, project planning, and personnel issues are more attractive right now.
You'd think that, but I worked with a guy going on 20 years of experience who seemed to be the embodiment of code first, ask questions later. He coded quickly and abundantly, but man it was crap code. He'd get assigned a story and go off and do what he thought it said but more often than not missed the real point of what the request was.
Planning is like 80% of the work to me.
Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things they've not yet thought about.
This Android component doesn't allow styling without modifying the library object itself, for no good reason aside from whichever intern wrote it was lazy and nobody at Google cares about anything, so it made it through.
Ulimit exists, guess I should go fuck myself.
AWS says it supports this language for lambdas but it kinda doesn't if you look at the bug tracker for the tools.
This fancy new build tool someone else chose breaks this third party package in a way that goes away immediately if I just swap it for the old, uncool build tool.
That kind of crap. And it's the worst part of programming. There are also "real" problems, but they're the minority.
Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is.
You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks.
But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, how to roll it back if you screw up, etc.
I find that many people use agile as an excuse to ignore these questions and just pile up fixes on top of prototypes.
Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done.
Waterfall never existed as some kind of formal process. It was invented as an illustrative device.
I did, and here's the direct quotes:
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
As I said, the cycle length is shortened, yet...
> Continuous attention to technical excellence and good design enhances agility.
...design is not removed from the process, but kept as a cornerstone.
> Simplicity--the art of maximizing the amount of work not done--is essential.
This one might be a bit more of a stretch, but I see here the benefit of designing a simple, elegant solution rather than doing work straight ahead.
In any case, I don't fully agree with the agile manifesto, even when correctly implemented. Particularly this quote is the bane of my existence:
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Which you can identify as the very opposite of the ever popular 'this meeting could have been an email'.
Once you put it together, you'll realize that the message is:
1. Deliver software. You won't have a manager hounding you to do so.
2. Do good work. You won't have a manager questioning what you've done.
3. Don't spend more time programming than you need to. You need time for managerial tasks.
4. Meet with your teammates. You won't have a manager to act as the go-between.
My opinion is based on being a software engineer (junior through principal) at small, medium, and fortune 100 companies. I also have years of experience as an engineering manager.
It’s silly to be absolute about it, but I think there’s probably a large overlap between competent engineers and people that agree that the agile manifesto is generally a good thing.
What says that? The Manifesto is there to help guide you if your group chooses to forego managers, but it doesn't suggest not having managers is the right tool for the job. An engineer more than anyone should understand the concept of tradeoffs.
We're building entire skyscrapers and cathedrals by gluing a few toothpicks together at a time. Because that's all there's time for in a sprint. It shows in the quality of modern software, and the never-ending updates necessary to keep them from collapsing.
Of course planning it all out years in advance and then executing blindly on those plans without ever correcting course wouldn't make sense either. But maybe a middle ground could be better than either extreme.
I get what you're saying though, I definitely don't think I'm solving all my problems before ever starting the code, but I definitely always finish solving the problem before I finish the code, and usually early enough that the rest of implementation drags even if there are quirks and edge cases to work out.
The main lesson I've drawn is that never propose a technical solution that you didn't PoC and that you only have validated the parts of the system you implemented. Deletion is often harder than creation.
You have to do the stuff you don't like to get to stuff you do sometimes.
I can relate to this so much sometimes. Right now I'm putting off programming because the ticket I have I've already thought through in my head and now I'm sitting here goofing off on here and reddit because I just don't want to do the actual work part.
And as another commenter chimed in, its true that some problems only emerge once you start writing the code. But that's alright, its part of the process. The planning isn't so much to figure out every problem ever, but to model the known problems so that programming the solutions can begin. I go back and forth between white-boarding and coding as things emerge.
I always tell myself that if I'm sitting at the keyboard and I don't know what to type, it's time to go back to the whiteboard because I'm not understanding the problem.
edit: clarity
Two factors cause this to be an exercise in futility:
1. Job mobility
People are incentivized to job hop. Most employees are ramping into a new role, coasting/leetcoding while they interview elsewhere, or preparing to transfer to a new role in your company.
In a 1.5 year employment window in a given role, a team member may only be getting 6 months of productive time in the new work paradigm.
2. Capricious Management culture
The new era of tech has ushered in a fickle type of boss who has constant pivots, realignments, and shifting priorities. They speak of some utopian future for your organization and paint a picture that everything is always 'in transition'.
This means that nobody seriously considers your CICD or Agile paradigm to be a permanent thing... you only get half hearted attempts to follow it for the 8 months that it lasts before a new paradigm is forced onto your group.
Overviews of the problem are more in the realm of spec rather than implementation planning and is another issue altogether. Of course you need to know what you're solving, but it is my point that I don't need to write a detailed document on how I'm going to solve most everyday problems when I can jump into the code and progressively work from there using the tools provided by the language.
At my work though, if you're going to adopt a major framework or service, you need a doc explaining why you chose that one. It's a big decision that will last years.
If the problem is solved before I write code I’m not really interested in writing code. I crave problems that require experimentation, where the solution isn’t obvious.
On the other hand, it’s a reason I have trouble completing projects. Once I prove to myself it’s feasible I get bored with finishing it…
Have you worked on problem spaces that are either so vague, or so large that it’s impossible to form a mental model?
That’s when I just jump into coding, because there’s no alternatives. Whatever I produce will make the powers that be able to crystalize what they actually want.
The mistake is by other people who think that your first efforts represent the product and need to be shipped.
It almost works except that no one really understands the problems you're presenting because they've all got their own problems to deal with. It's more helpful as a duck.
Not all companies were waterfall, they kind of just "did things" without any well defined process. This was how things were until roughly the early 2010's. I remember working for weeks, after a couple of whiteboard sessions. You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins.
I don’t necessarily agree that things were better - but “agile” was supposed to fix the things that were bad back then but has since somehow managed to morph into exactly the same problems that it was originally purported to solve.
Your comment has the sparkle of nostalgia for glory days gone by.
Nobody knew what bugs existed or what features were needed until someone in sales who talked to a customer ran downstairs and recapped their last customer call.
Builds were not reproducible. How we decided what we released to the world was we'd poll the room. Who could actually compile the software today without errors? That person would build whatever was on his workstation, debug symbols and all (because the release builds crashed), and package it up for the customer.
How did we know what we were releasing works? There was one QA guy, who worked on the assembly line. They'd flash the software onto a single device, and make sure it still booted. Ship it!
How did we plan what we were doing for the next N weeks and months? This one's easy--we didn't! The CEO or someone in sales would run downstairs and tell us "We just sold XYZ feature to a customer. We need everyone to drop everything and make this by the date we also negotiated with the customer!"
I think "no process" software development only works for a single developer, or for a very small (less than 3 person) team of absolute experts. Mix a single junior person into the team or add more than 3 or so developers, and it's going to be chaos.
Planning meeting, ad hoc meeting doing the work then weekly/bi-weekly show and tells to show progress. Sounds like...some version of agile?
Remember agile and the XP movement that preceded it was invented by software makers, who had observed the pattern you describe and decided to be self-conscious about it.
You need first to make it work, later to make it perform, then to optimize it, finally to trash and replace it. Many go right away to optimize then stall.
,,Individuals and interactions over processes and tools''
What you are describing is the opposite of agile
Robert Martin (one of the creators of the agile manifesto) explains it quite well in ,,Clean Code'' presentation:
https://www.youtube.com/watch?v=7EmboKQH8lM
The whole presentation should be a must watch by all engineers so that they understand what _is_ agile to the point when they know it better than product / project managers / non-tech people.
It's hard to get a better description than the original source, and no non-tech person has authority to override the real agile at that point.
It's basically a bunch of experienced engineers getting together for a weekend warning inexperienced engineers about newbie mistakes, like obsessing too much about new shiny tools / frameworks / processes created by people from the past, or leaving mess behind.
At Google we were doing mostly agile actually (didn't really have any complex process, but had quarterly goals to check ourselfs and get feedback, also weekly check if we are going in the right direction).
,,this week'' snippets about what we're going to do this week.
All light stuff to make sure that it doesn't hinder real coding work.
Cross team work was much more messy of course, but inside teams this worked fine.
At another small company I worked it was almost the same, we just didn't call it agile.
That's called making it up. While it may have worked for that organization, I assure you it falls it a heap 99.9% of the time large software is developed that way.
"Mid 2000s" for some of us at some places, unfortunately.
Personally I think I enjoy solving problems with just enough tech. I roll my eyes when I see hyped tech/practices tossed in with everything. I know somebody that works in a hospital as a unit clerk, and they supposedly use JIRA and are Agile.
In short, there's a lot of fake work.
I am passionate about programming, even the parts you don't enjoy like rearchitecting and refactoring, those mean "applying knowledge to solve a problem" which I really enjoy.
I detest the bureaucracy around these (teams, requirements, deadlines, etc.), but those come as either life requirements (a company must make money in a reasonable manner), or the current status quo of your entire project and its teams.
The latter at least can be resolved by leaving your company.
(I don't necessarily think this means management is bad. Software engineering is always a balance between "do the right thing even if it takes much longer initially" and "actually ship code in a reasonable timeframe so we don't go out of business." You need advocates for both approaches and hopefully the culture is healthy enough for a happy medium to be found)
I would say many of the time engineers don't want to do something it's a better solution but they'll claim some technical reason why their way is better.
A good example of this is, I was working on a geo search api endpoint that had to work with the TPEG specs. The system was powered by AWS Lambda, which can scale, Elasticsearch which can scale, redis which can scale, etc. The system couldn't scale. It fell on it's ass at 500 requests per second. The part that fell on it's ass was Elasticsearch. Realistically, at 500 reads per second you know it's not really elasticsearch's fault but a data model problem. These are literally excuses that were given:
* "We shouldn't do those kinds of searches because they don't scale." - We were contractually obligated to do this search with a 2 million eur penalty fee if we didn't.
* "The issue is we're returning too much data" - We weren't having timeout issue, we were having issues with running out of CPU.
* "We should hire an elasticsearch consultant to solve it" - We should be able to make Elasticsearch go more than 1% of it's benchmarks. Which when Elasticsearch's benchmarks were brought up "Benchmark's are designed in a certain way to scale" - Which is true when you're getting 20k and they're getting 30k. But when you get 500 and they get 50k - yea that isn't standing up.
* "The scale is too much. We'll need to serve millions of requests per second at their highest scale. And no one can do that." - Basically, trying to bamboozle non techies, mixing up database reads with end user requests. It's literally so easy with Elasticsearch you can't even find a blog post on it because it's not worth bragging about. YOu can find people talking about 1 million writes per second tho.
The problem was ignored until the point we almost got sued and looked really bad to our biggest customer. This caused all sorts of issues for everyone. All because they didn't want to do the hardwork of figuring out how to build a data model that can scale easily. They ened up spending 30k a month on elasticsearch clusters from AWS to get 500 requests per second. They needed something like 196 CPUS and terrabytes of RAM to serve 500 requests per second of data that was 2-3MB RAW but 150 KB compressed. While on the surface it could appear like they wanted to do a good job, the reality was this was one of many areas that were too difficult for them to deal with so they didn't want to solve it. And people will say that's just a bad team, I've seen that repeatedly. People shy away from the hard to do things.
I would say it sounds more like "they didn't have the chops/experience to do it" and less like "they didn't want to do it?"
In situations like that my instinct as a developer is to figure out the hard part first. Some sort of prototype to prove that hey, this design works and can serve X requests per second. In other words some basic prototyping and research... a "spike" in scrum/agile terms.
Managers have viewed this as insanity. They think optimization is something you can sprinkle on later. Surprisingly a lot of developers do too.
I've been on two projects where this situation happened. In one I was able to save the project. In the other I wasn't.
Thanks for replying BTW!
The requirements to make things scale- Being part of a team with procedures and processes kills the fun for me.