[itsmejeff]

The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs to stakeholders. They don’t complain about business constraints and they put out stellar work.

“business people” most often do understand what makes the money flow through their company (and into engineers’ bank accounts) and they typically make decisions in order to maximize good business outcomes. Sure they don’t understand the technical details of an engineer’s work, but the engineers are far from understanding all of the things that must fall into place besides lines of code in order for their paycheck to clear. It’s not always vital to the business to have a good code base. Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.

(fwiw I’m a director-level engineer so I’m technical but bordering on being a “business person”)

[bcrosby95]

In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business constraint can have an outsized impact on development costs. Oftentimes these decisions are even made by business people that think they are making things easier but are actually doing the exact opposite.

[JumpCrisscross]

> simply doing the work without complaint is one of the most inefficient relationships with a programmer

There is a difference between complaining, voicing opposition and articulating trade-offs less technical people may not be familiar with.

[watwut]

I have worked in team where programmers constantly questioned business requirement - without having any understanding of business.

Eventually customer got tired of having to defend how many statuses he wanted in combobox or what process their company want to use.

By that I want to say, there is definitely such a thing as programmer not willing to consider business point of view for a second and thus being impossible to work with.

[makach]

IMO that sounds like a bad team.

It is vital to understand business needs. A lot of times businesses want changes that are hard, and very hard to implement. It is our responsibility to work with the customer to come up with a solution. The customer must accept the consequences that come with their requested change.

Unfortunately, some things are impossible to do. It is never good to be the bearer of bad news - I have myself told that we cannot do it this way, but I have always given a thorough explanation of why it is impossible and suggested workarounds and alternatives. I think sometimes this behavior can be the difference between the perception of being impossible to work with and helpful.

Truth is, it takes a lot of effort to balance your work against the ever-changing set of requirements coming from your stakeholders.

[zachrose]

Sometimes it’s hard to understand the business. I see this happen when developers are considered fungible resources to implement a spec. If their only visibility into the business problem is through a proposed solution, then yeah, questions about how many statuses are supposed to be in the combobox are to be expected.

[watwut]

It was not issue of ambiguity. Specification was clear. It was issue of programmer assuming that customer is wrong all the time and basically wanting the customer wrong. The statuses were right, but the programmer fought to merge few of them into one, because it looked "simpler" to him.

By questioning in don't mean having honest questions nor trying to understand, but being convinced that there must be mistake and forcing customer to defend every tiny choice.

And sometimes the customer wants radiobox instead of combobox are just wants to have it without having to spend 20min on meting to defend the choice.

[agentultra]

On the other side I've had customers ask for things that are impossible or against best practices and their own interests.

For example, password requirements. Many companies are not aware of the latest best practices and guidelines and request that we block browsers from generating or remembering passwords in password fields. Or they give us a list of draconian password requirements that are clearly debunked by the latest guidelines.

Or they ask us to basically break the HTML spec.

Like I tell my four year old son, I'd love to get a million dollars but I'm not going to get it because I stamp my feet and demand it.

Trade-offs need to be made on both sides. I agree that an engineer that doesn't provide alternatives when a customer demand is not technically feasible should be corrected. However the customer should be prepared to choose from those alternatives or change their demands as well. The first step to success is shipping and the most common reason for software projects shipping late is a failure to start. I'm not against firing bad customers.

It's much easier to ship without a contentious feature and figure out how to add it later than to delay shipping (for certain features within reason, of course -- please don't ship half-baked security libraries or aviation control software).

[watwut]

Yes, but that is different situation.

I was specifically talking about situation where requirements are possible and not ambiguos. And where engineers starts "knowing" customer is wrong and keep knowing it despite it regularly turns out it was enginers lack of domain knowledge.

There is no trade off between these two situations.

I don't know what you mean by breaking html spec. Browsers keep it and we work either with it or around it?

[legulere]

The problem here is that business people don’t understand the details of the business requirements or the model of it in the code.

[thrower123]

Sometimes things have been trundling along on so much fuzz and handwaving that nobody actually knows how things are supposed to work when it gets down to formalizing them into a set of rules that could be implemented in code. Many such cases.

[onion2k]

If someone doesn't understand something it's because it's either not been explained well enough or that person doesn't have the background necessary to understand it. Either they need more information or they shouldn't be making decisions about it.

If the problem is that the issue hasn't been explained well enough then the developers need to work harder to better explain what the problems are and why they're problems.

If the problem is that the business person doesn't have the necessary background to understand the issue then you have a huge problem. That person is going to be a problem at every step. I don't envy anyone in that situation. In the past 25 years of development I've never actually encountered that situation though.

[gen220]

I’d put forward that there’s one more possibility: the person’s paycheck is contingent on them not understanding.

Unfortunately, some business people are compensated as direct function of revenue (growth), even though they have to pull engineering levers to obtain that delta in revenue.

For a lot of these people, once they’re convinced that doing X will lead to growth, no explanation will convince them that it isn’t worth it.

[amelius]

Engineers always have to give time estimates for their work. This is their way of complaining.

[xaybey]

Honest question - is this a part of your hiring pitch? "Our engineers don't complain about business constraints" is a red flag if I ever heard one.

[stiray]

... and is quite a funny statement. If "our" engineers dont "complain", then someone is not listening. Or you have really bad company culture / recruiting / engineering. The DUTY of engineer is to complain to bussiness decisions as they are quite frequent orthagonal to what does make sense to do and in which order.

Make sockets as first priority and then write tcp stack as "unneeded"/postponed is quite frequent from a bussiness standpoint. Not complaining about situations like this is just hurting the bussiness.

[yibg]

I think depends on what constitutes the “complaint”. If it’s just a bunch of griping with no suggestion for an alternative it’s not very constructive. Clearly engineers shouldn’t just build whatever they are told, but not caring enough about the business constraints is also bad. Like it or not at most places the software serves the business. Yes you want to engineer things so they are maintainable, performant etc, but if it doesn’t meet the business needs then none of that really matters. I’ve worked with engineers for example that outright refused to build things that are clearly needed by customers, for “technical reasons”. The result, good software that no one used.

[stiray]

On the other side, you have software that doesnt have promised features, is late etc. Bussiness side should always work with engineering side (which is more than not an exception) and the engineering side should never reveal what is possible to marketing (so they sell what they have instead of selling the... clouds... ehm... need better wording... vapors).

[mschuster91]

> Yes you want to engineer things so they are maintainable, performant etc, but if it doesn’t meet the business needs then none of that really matters. I’ve worked with engineers for example that outright refused to build things that are clearly needed by customers, for “technical reasons”.

The core problem is that too often business needs are dogmatic and management is too entrenched to fix it.

This is the reason why so many large-scale IT/digitalization projects end up colossal clusterfucks: no one on customer side has the spine to say "our processes and workflows were made in an age where people did things by hand, let us modernize them while we're already at it".

[Hackbraten]

Depends. To

> clearly articulate trade offs to stakeholders

may be the constructive cousin of complaining.

[nwallin]

> write good code within the constraints of a fast paced business environment [...] It’s not always vital to the business to have a good code base.

You're on the edge of contradicting yourself.

If the business environment is fast paced, ie your development process for ingesting features and specifying behavior is ad hoc, ("we are agile/do scrum, except we service requests from customers immediately as they come in instead of waiting until the next sprint") it's absolutely vital to the business to have a good code base.

Being able to make rapid changes without breaking everything requires a good code base. If your code base is full of landmines, you necessarily cannot send an average coder out to implement some average feature, because they'll necessarily have to (re-)teach themselves about half the idiosyncrasies of the codebase before they can do anything.

It's fine to have a shitty code base if your business environment moves stodgingly. ("You want a new form in the UI? OK great! We need a scope of work, a formal specification, we will charge you by the hour, you will need to pay us to recertify the entire product. Let's set up a meeting with contracting and legal next quarter to iron out the details.")

In my experience, the people who implement features quickly in a shitty codebases do so by breaking stuff in non obvious ways. This includes myself. This is fine for my organization because we only ship once every six months, and we only ship anything after two months of exhaustive manual testing. If the organization just decided, "we're a fast paced organization now, now we ship every two weeks" we'd lose all our customers fairly quickly as a result of the precipitous decline of the quality of our product.

I suppose fast paced business environment+shitty codebase is also ok if the goal is just to sell the company as soon as possible. But that's a personal objective, (and a selfish one) not a business objective.

[Tade0]

I've worked with such people and on applications made by them.

All that is usually done at the expense of others - be it teammates or future maintainers.

It works great for MVPs and such, but falls flat on its face when you have to add new features to a three year old application, whose original creator moved on a while ago.

[acephal]

This is exactly the situation I'm in at my job and I'm the only developer left from the MVP team, which was headed by a consultant whose scope was supposed to be smaller but convinced management, when they would not budge or listen at all to their in-house leads (I was a junior at the time) on the same issues, that they'd get results if they gave him the project (and a helluva paycheck). To his credit, he helped us put out a decent MVP, but he booked it when the company wouldn't give him an even more insane pay raise to stay on full-time and it turned out the MVP was not scalable and was designed for a different case than the one our company had and so suffered perf issues the moment things got serious. But management was okay with all this cause they got the MVP they wanted to show off to potential acquirers and-lo-behold the company got sold, that management disappeared, and I'm stuck behind walls of intervening actors from addressing fundamental issues in the design

[Tade0]

Interesting. I assume nobody figured that it's high time to rewrite the damn thing?

[specialist]

Every (successful) rewrite I've ever done was in secret.

I once spent 6 months fixing someone else's MVP. Every bug fix exposed 2 more. I begged for a do over. Nope, we've invested too much money to abandon.

Once I understand the problem well enough, I banged out a full rewrite in two weeks. I had just one bug before release (one of the trig equations had the wrong sign, facepalm slap).

[alexandercrohde]

>> “business people” ... and they typically make decisions in order to maximize good business outcomes.

You had me until this statement. It's been my observation that "business people" are usually self-interested manipulators who hire people they don't need if it makes them look important, game/trick OKRs, hide all failures from their superiors (and would fire you if you went behind their back), often damage brand trust/equity to try to get good metrics for a quarter (e.g. google), willingly let massive problems (e.g. security holes a la equifax) fall on the floor rather than risk being associated with problem by helping.

Not all, but more than half.

[thomk]

I would not call it 'complaining' to point out a business constraint, I would call it part of the job.

To make it easier there really are only 2 business constraints: Time and Money. Everything can roll up to one or both of those.

I'd also like to note that asking an engineer to estimate a project, is work. That work (creating the estimate) takes both time and money. The more time and money engineers spend on creating an estimate, the more accurate (and valuable) it will be.

Here. This is an estimate for almost every business software project: Between $0 and $100MM. That took me no time and as a result, has no value.

The other end of that spectrum is an estimate with perfect accuracy and full value. Meaning -- we know, to the penny, what it is going to cost. An estimate like that is going to be EXPENSIVE and might even eclipse the cost of the entire software project.

Knowing that creating estimates take time and money, the question inevitably becomes "Well how much will it take to create the estimate?"

The answer comes down to: How much do you want to invest in it? Or better put: How important is estimate accuracy to you?

Business people decide the value of things, rely on that. "What is the dollar value of this to the business?" is a legitimate question to ask to a business person. If it's worth $1, then use my estimate above. If it's worth $1MM then the next question is: What percentage of that inevitable end value is it worth to spend on the estimate?

Most of the time the number that comes back is not derived from some magical corporate formula, it's gut feel. Which by the way is essentially arbitrary, which I wouldn't call useless. But let's call it what it is, it's a number that is palatable to the business to lose.

So, given that number, we now know how much time to spend. Your accuracy will directly reflect that amount. If we want to be more accurate, we'll have to spend more money.

Business people are responsible for the money and engineers can not manufacture more time.

Rely on both of those.

[thdrdt]

I think what you mean is: the best programmers I know add value to the company.

As a freelance programmer I had to learn this. Companies don't give anything about the language, the VCS, the LOC, spaces or tabs, or anything unrelated to them.

You just add value to the company by creating great software they can use. This also means software that can be maintained and updated.

Some people in this thread complain about the "They don’t complain about business constraints". But when you start complaining about their business constraints, how can you add value to their business? You can only add value when you think about how you can create something that works best for them to keep those constraints. And ofcourse this includes discussing constraints when you are sure you have a great idea to make them better, but most of the time other people thought better and harder about those constraints than you did.

Edit: maybe it is unclear what you mean by "business constraints". In my mind you are talking about the company business, but others might thing about programming business logic.

[ichik]

> “business people” most often do understand what makes the money flow through their company

My anecdata for the last 15+ years doesn't support this claim.

[coldcode]

Mine goes back almost 4 decades, and understanding the business and tradeoffs is largely hit and miss with executives at all levels (also ran two startups in the days before the web). I've dealt with CEOs who understood everything and those who knew less than nothing; also seen engineers who understood nothing in business or development or both and those with a great deal of knowledge who could suggest changes and improvements that made sense to everyone. But I think the negative versions were far more common than the positive ones in every kind and size of company.

Sometimes dumb people can still be lucky and make money (one place was dumb all around but their business was a unassailable monopoly, and another had 40 years of dumb customers who agreed to terrible annuities so failure would take decades to happen no matter what was done) and sometimes bad decisions or understanding in business or tech lead directly to failure.

There is no single type of success or failure in either business or tech.

[harshalizee]

This sounds exactly like the kind of engineers I never want to work with. That's just a breeding grounds for yes men with zero interest in challenging the status quo. Nothing personal, but you are the type of director I would also not like to work with. Three management style described sounds like a walking, talking red flag.

[specialist]

I am just a fair programmer.

But I create great insights. Whole new ways to see a problem. Making the intractable and complex simple and obvious with a novel mental model.

For instance, I replaced a high end CAD/Illustrator style print production workflow with a simple form. Answer some questions and out pops a production plan.

It took me 4 years to earn that insight. The entire industry modeled the flow information exactly backwards (https://en.wikipedia.org/wiki/Job_Definition_Format). It took me forever to overcome my initial misunderstand of the problem -- I mean really, how conceited am I to think everyone else is wrong and no one else thought of this before me -- and see the problem like the production workers do. I had to bridge the domains of print production and software design.

Alas, it's been a while since I've had a gig which could afford that kind of investment. My last gig, recommenders for fashion, which turned out to be a complete hoax, devs were slaves to JIRA, "just do 80%" and move on, throw everything away every 2 years, unless it's "legacy", in which case just suffer with it.

I wonder if there's much room left for dinosaurs like me.

[CaptArmchair]

> It’s not always vital to the business to have a good code base.

Many engineers may cringe at this... but this is true. Code is only as good as it is able to fulfill a business need: that is help the organization meet its strategic goals.

Technical constraints - maintainability, security, performance,... - are really subservient to that principle.

That is, they aren't unimportant. Rather, their importance is relevant - or a priority - in so far that they help achieve the higher goals.

... but this isn't a universal maxim!

> Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.

An employer/employee relationship is very much a business deal between humans. An employee sells expertise and potential for a fixed amount of time in exchange for a fixed salary. As with any deal, such business relationships extend beyond simple monetary compensation. Especially because employees subjugate themselves to the authority of their employer, making it inherently a skewed relationship.

When humans invest their time and effort in a venture, they hope to get a due sense of satisfaction and self-actualization from doing so. That's where aligning values makes all the difference.

What many business people fail to see is that employees don't identify themselves as resources, liabilities or labor. They see themselves as partners who hope to make a meaningful contribution, and they are willing to do so provided that they are treated as such: with a due sense of empathy and respect for their opinions, what motivates them to come to work each day; and so on.

If they don't get that, two things might happen. Either employees will walk out rather quickly, or - worst - they stay and will only give you the bare minimum of their efforts - living for the weekends - wasting both their own and your time.

It's true that companies aren't obligated to keep employees forever or that they can be let go if both parties want different things ...

... but publicly stating that any employer/employee relationship is "replaceable" without that nuance, is the shortest route towards foundering any hopes to attract potential hires who care about your business at all.

> They don’t complain about business constraints and they put out stellar work.

Given the above, humans will also factor in the moral and ethical side of what they are doing. And they can, will and should criticize those business constraints if those don't align with what they feel is "good" or "morally sound".

Business constraints aren't just limited to implementing some weird feature. That's just the output of a business constraint. Neither are styling rules or automated tests business constraints. Nope. it's far more then that. It's workplace culture as a whole. It's the shared values that are espoused on a day-to-day basis by everyone.

It's normal to have some level of conflict or tension as the net result is an ever-moving compromise.

Expecting that employees will never complain and only put out stellar work pretty much makes any healthy discussion moot. It's a non-argument as "stellar" is only meaningful in the eye of the beholder. All it does is create the perception that employees are seen as automatons.

Again, when employees pick up on this; they will either walk out or - worst - stick around and waste yours and their own time only doing the bare minimum to cash a paycheck.

In the short run, the bottom line of a company may reflect the financial benefits of optimizing for efficiency. But in the long run; not taking the human factor into account isn't sustainable at all. Neither for the employees, nor the business owners.

[mrmanner]

>> They don’t complain about business constraints and they put out stellar work.

> Given the above, humans will also factor in the moral and ethical side of what they are doing. And they can, will and should criticize those business constraints if those don't align with what they feel is "good" or "morally sound".

My thought after reading the article was that the author seemed to consider writing good code, maintainable code, and having a strategy prioritizing long term over short term needs as moral imperatives. Or at least the words and terms used were ones I often hear and use when discussing ethics and morals.

Which made me think, do many engineers consider these things as ethical decisions, rather than just business choices?

Personally I enjoy being involved in strategic decisions, both providing input and opinion - but I also see the value in adhering to a strategy once decided even if it isn’t the one I’d advocate for if it was up for discussion. For ethical decisions I’d reason differently - it’s not ok to break laws or destroy lives (etc etc) just because a business decision said so.

[pdimitar]

> My thought after reading the article was that the author seemed to consider writing good code, maintainable code, and having a strategy prioritizing long term over short term needs as moral imperatives. Or at least the words and terms used were ones I often hear and use when discussing ethics and morals.

I don't think the article's author said this. In my eyes he meant it more like "at least give us SOME breathing room to do our best engineering work!" -- meaning give some time for refactors, for changing tooling, for stepping back for 1-2 months and just looking at the whole thing in general.

Creativity needs time for pondering and reflection. Chasing ruthless and practically impossible deadlines while having to systemically ignore everything that made you a good engineer in the first place makes for a toxic employee<->employer relationship. And one that rarely ends well.

[29athrowaway]

Not every business model is the same.

When you only have short term goals, sustainability is doesn't make sense.

[cb504]

@ismejeff, sorry but you are (probably) a business person.

- is an IDE open on your desktop right now?

- how many commits have you done this year?

Talking about code and software isn't anywhere near the same as being a programmer. If I am wrong about you, I apologize; you are the exception.