Hacker News Reader

Comment by ethbr0 | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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.

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.

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+.

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".

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.

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.

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.

>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

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.

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.

Or this company is bought up, which was there first and therefore has the larger financial reserves.

>"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. =)

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.

Both are in a strong first mover / network effect industry (social). It's definitely an optimization in certain cases.

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.

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.

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

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.

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

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.

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

> You should know this already. =P

Groan. This comment could make its point without assuming what the other party knows or doesn't.

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.

"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.

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.

> 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.

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.

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.

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.

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.

These are often some highest paying and prestigious jobs in large companies.

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.

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?

Think OKRs.

"Is the high level goal for this software critical."

If yes. Then, people will give the problem the full attention it deserves.

And once you have their full attention, you are more likely to get their cooperation to being actually productive.

If no.

You're going to have a bad time.

[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!

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.

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

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 :)

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.

That is incorrect usage though; every rule 'generally works but sometimes doesn't' if we account for people not observing it.

But pointing out that language rules aren't something that people strictly adhere to, with rigorous logic, is a useful observation.

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.

> That is incorrect usage though

We don't need no education

You wouldn't be here quoting that line if it were correct.

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.

> "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.

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.

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.

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?

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.

Sure, if he is a junior engineer with the proverbial "20x 1 year of experience" and is paid like one.

> 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.

> 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.

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.

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.

> 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.

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.

Rejecting meetings comes at a cost.

> 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?

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.

"Consensus about any topic is impossible because political speech has become more polarized"

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.

> 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.

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.

Reply on news.ycombinator.com