All of these books fall into the category of rounding out my world view. I’m an engineer, and spent nearly 100% of 10-12 years of my life (school plus early career) focused solely on engineering topics. These books have made me drastically more effective at achieving personal and professional goals, especially ones that require cooperation of other people.
My process is to dig in and really try to apply the knowledge in some place where it is required to solve the problem.
This has never failed me, but it’s hard, because it’s WORK. You can’t just sit and consume material (though consuming material is important). My typical strategy for consumption of material is to do such when I hit a road block in the application of my knowledge.
A few concrete examples to get the idea:
Want to learn about how cars work? Don’t take your car to a mechanic, force yourself to fix it.
Want to learn about electronics? Build an electronics project.
Want to learn about machine learning? Build an actual ML powered software application.
Want to learn about math? Use it to solve a real problem (physics/engineering has some of the most concrete representations of applied math from algebra to through differential equations, etc)
More difficult subjects will take more “projects” in order for you to gain in-depth knowledge. However, nothing beats experience at applying the knowledge in order to achieve true mastery.
Where some folks get hung up is they think they need to pass some knowledge threshold before they begin to try to apply it. I think this is false, for any application where a lack of knowledge is not actually dangerous. The sooner you try to apply what you know, the sooner you will master the subject.
I really like thought exercises like this, but find it troublesome when authors (like this one) do not offer alternatives that address the weakness of the common approach, they just just point the weaknesses out and metaphorically “shrug”.
Left with this, people will still revert to the status quo because they’ve been offered no true alternative that provides more value.
This may be a bit of a paradigm shift on the original question, but I’ve found that arranging my software and project in such a way that “cognitive overhead” is minimized will make startup cost extremely low.
If the code is very simple to reason about at a high level, you won’t need to remember many details. If your dev environment is stateless such that simply “opening the project” (for me, cd-ing into the project directory in my terminal) will automatically set up everything you need to start iteratively developing, you won’t have to focus mental energy on project setup.
This leaves you free to really only worry about the exact thing you were doing.
I’ve been pondering this a lot lately, as an engineering leader.
Masters in my organization have an extremely high ratio of value shipped to hours worked.
This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such that the cost of adding more value to the system remains constant as the system grows in complexity.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder.
The importance of good politics cannot be understated. Politics in this case is roughly defined as getting people onboard with your plans.
While your bridge analogy is true, I feel it's even more valuable to have an informed view for what's on the other end of that bridge. If you work the politics and use all the right materials to build an efficient bridge that's great. But a wonderful bridge to nowhere is still a bridge to nowhere.
I say this because as a finance guy, I've been on lots of projects that look great on a spreadsheet and marketing, sales, or somebody else is really pushing for the investment. That's the point where a technical person takes over and builds what's asked, or a really great technical person may ask a few questions and raise a few points nobody else considered and the whole bubble bursts as we realize it's not feasible/or we can test it in a certain way before investing big time/money into it.
Probably not mastery of SE as OP asked. But mastery as a business partner within an organization.
That sounds amazing, sadly in a lot of organisations that isn't how it pans out.
Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out.
The crux of this is that many of those people who carry the weight in decision making don't actually carry any risk or responsibility for delivery. Given the scale of engineering and time to deliver, by the time it comes to fruition they've moved on, so they never experience accountability for ignoring the advice.
For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built.
(My favourite time was when a (really smart, to be fair) software engineer rediscovered the normal distribution while looking for a way to reduce storage requirements for an analytics product).
If you have a load of smart engineers, sometimes it can be a more successful strategy to just build something than to pay EY £250k to do market analysis, get a load of execs bought in who then will "make it work" even if it shouldn't, or kill it off even if they shouldn't, and then finally get a committee-written spec handed over to be built in a rush.
Sure, there are pathologies at both ends of the spectrum. I do think it's worthwhile (particularly here), that software engineers/technical people are subject to their own set of development pathologies.
True. I’ve witness all of these things as well. I’m not implying that organizational decision making is perfect if only it had better technical people providing inputs by any means.
Again as a finance guy, this is a major skill I have attempted to develop for myself/team. When projects spin up, I’m typically at forefront and involved in every project technical or not (controlling the purse strings). Many finance guys are know it all’s TBH. They build their ROI models, etc. and making dozens of assumptions it’s then treated as gospel. For some reason, it’s valid to ask “why is this project underperforming our expectations” but it’s often taboo to ask “did our expectations even make sense”. I try to change that where it exists too.
All to say, people like me find people at the onset of the project to gather inputs. If I know you as well versed with track record of valuable insights, I’m more likely to reach out early. If I have worked with you at this stage and you your input is just one of “we need specs/tell us what to build and we can build it” you’ve not added any value to the conversation and I’m likely to not include you next time because I know I just need to bring you specs once project is approved and that’s a different conversation for another day.
This is why I say “business partner”. Being able to understand your company, the politics within, how decisions are made, where you can inject value along the way. These are all traits of people with fast career growth in slower growing firms. You transform from Programmer #13 to people knowing and respecting your name. This is important in talent reviews, etc.
Good one. Another on the same lines, and also related to your parent comment's point about politics, is:
Getting the users in the org to, you know, actually use that well-specced, well-built project, which was delivered within time and budget (or with only a small overrun). I mean, use it at all, or use it enough for it to deliver its benefits. Real life issue. Seen it on at least a few projects I've worked on, including two early in my career. Inertia, luddite fears, turf wars can be some of the causes.
The most difficult hurdle is that there's never that direct communication between the finance guy and the tech guy. Projects tend to get lost in translation, where you have multiple layers of departments and emails and roles playing telephone. If an organization can have that direct finance-to-tech guy/gal link, it would be the most effective way to provide the most effective value imo.
It’s definitely a problem worth focus. I recommend networking with some of the finance folks. It’s as simple as a lunch meeting, ask them about some of the projects that are in planning phase, offer your assistance. You’ll have to figure out what is the post-COVID equivalent.
I find some in finance and IT get along fairly well and can build a bigger rapport fairly easy. We’re all excel nerds and many of us have taught ourselves how to program to an extent (VBA, etc).
Depending on the organization, we tend to be more focused on leadership support. A junior analyst will get much more face time with VP and up than down. So that’s part of the problem is those connections just don’t always exist. When they do, it might be with an IT director which has maybe become too far removed from codebase or implementation challenges. It happens with every department within the organization, not just IT. My experience is outside the software industry so may work a little different if sole function of the company is software.
In your analogy if I get really good at getting stuff passed through city council, what would I optimize for ?
A: Building better bridges ?
Or B: building better money making bridges (potentially of of inferior quality) ?
I'd bet there are more takers for B. And at that point we now have better city council optimizers than better bridge builders.
Lets say we now make a team of some folks from both groups. Now who's going to able to get more people onboard their plans? Its the city council optimizers again. And now some bridge builders figure it out and become better optimizers than builders.
We then take it a step further and add competing teams. Same thing repeats. The team better at city council optimizing beat the better builders all the time.
In this whole process its the quality of the bridges that stays the same ( in most cases it goes down) and the costs of it keep going up.
My sad, unfortunate observations in the field.
Love to see a way out.
Edit: in this way of thinking , the assumption is that there are higher chances of making more money from poorer quality bridge than a more advanced, higher quality bridge. One exception to that is the strategy where you first provide better bridges at lower cost and then bump up the prices for maintenance.
Unfortunately this assumes that the politics of the city council is somewhat outcomes focused. If the mayor is intent on awarding the contract to her uncle no amount of 'soft skills' will help (and attempts to apply them may be counter-productive).
It's usually helpful to have an internal locus of control, and look for things in oneself (here, soft skills) that can be changed. However, sometimes reality just doesn't afford opportunities in a given situation. Accepting where that is that case means being able to extract oneself from a situation rather than wasting time on it.
This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
Leadership puts an architect in place because they don't have the time to care about code level details. I would personally mention it to leadership but frame it in a way that your work is being rejected but nobody is explaining to you why so that you can learn and do better next time.
Unfortunately in a large software engineering organization tact and political savvy is more important than raw engineering skill. Once you've been in the industry long enough, you'll understand it.
One of the problems that's common in organizations is that most of the work at the junior level is highly focused on individual contribution and that completely flips at some point in your career.
There's another facet to this which I think is far more important that OP question of "What [exactly] does mastery 'look like'?".
The more important question is "how do you cultivate mastery?" How does your organization get to a place where people can develop mastery instead of the organization trying to create it instantly by hiring "the right people"? Regardless of what people may claim, hiring is not a solved problem. It's _really_ hard to identify candidates that are true masters at what they do (let alone getting them to quit their job and join your team).
By the same token, it's also _really_ hard for true masters to find a place that understands their value and, more importantly, will allow them to do their thing and provide career satisfaction. A lot of talented people are locked out of jobs because someone thought their career trajectory wasn't quite right/impressive.
Training and mentorship, however, are better understood and have lower stakes. It makes me think of Bell Labs. I know a couple folks who worked there who had very "unimpressive" backgrounds, they started as techs but rubbed elbows with stellar talent in a place that cultivated discovery and collaboration. Over time while there and in other places they were able to rise to principal design engineers, beyond what many who went to elite universities achieve. They credit their formative years in Bell labs with getting them started on their career path.
The thing is, Bell Labs didn't have an epically selective hiring process, nor was the compensation insanely high. They provided an environment that _attracted_ people with mastery and those who were passionate about what they do, they developed talent within their walls rather than trying to merely buy it or find it.
This was for electrical engineers, but the same ideas can apply to software engineers.
That's a tough one. Often the sensibility about what needs to be done comes from hours/weeks/month/years hacking away at their codebase in their specific setting. Much of that has to be rebuilt from scratch in a new place. If you don't find that same connection with your work at the new place - or are unable to develop the relationships with your peers or your manager, you may not end up able to make that impact at the new place either.
I tend to encourage folks who come to me about quitting to explore opportunities within the team/organization/company before leaving so they can leverage all the social capital they've built up.
Absolutely, especially in bigger organisations where one part may be completely different in terms of how is organized and how is operating from another one.
I worked at one place that was a basket case and finally started to push back. The HR person seemed shocked that I was concerned with the business value of a project, but i had people telling me i wasnt worth what i was being paid -- I could show the next assignment had $0 in business value so if i spent more than 0 hours on it I'd just be digging myself a hole.
If you think something does not produce value and you have knowledge to back it up (you could think something is of no value if you don't know the big picture), and you are "forced" to do it anyway, then it all depends on pay. If you get a lot of money for this, you can exchange these later to fill any gaps that this will create or simply leave the co, unless you want to be known for doing fool's errands and stroking managers egos.
> They are able to discern and avoid work that does not provide value (this is often their greatest skill)
junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal.
A problem came up. Many of the libraries were government funded, and required physical possession of any books they purchased. I was in a meeting with the c-level execs, sales directors, and pms, and they were planning out the cost of building an organization that would produce a cd-rom version of the textbook products. They were going to need a large team to manage creating the books on cd, and for managing the production and mailing of the CDs when orders were received. It was going to cost a fortune.
I told them to hang on a minute: I'm already converting the xml for these books into html for display in the app. I can easily generate static html too, write it to disk, and generate an iso file, every time we publish a new book. Then I can add a download link in the webapp, and if they need a physical copy they can download and burn it to disk themselves. We'll include instructions. This will take me maybe an extra week, and we'll have no ongoing operational costs.
I think I got a $50 Amazon gift card for that suggestion. Or maybe a Starbucks card.
You have to be present in the meeting. All the places I have worked - and I have worked in many over 15 years - do not allow this. You need to be in a startup to be close enough to have this kind of impact. Agile just makes this situation worse. It's incredibly frustrating to be see the value you can add, but having no ability to make it happen.
Can't have pesky engineers with their pedestrian technical concerns mess with the business decision makers' thought process. A good engineer takes whatever the creative, smart visionary comes up with and implements it down to the smallest detail.
It seems like this value you brought in is "outside" the domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no?
(I wish you had gotten more thoroughly compensated for saving them a fortune.)
If your only skill is being able to write code, your skillset is relatively weak.
We are called Software Engineers, but what we really are is people who solve problems with code.
The important part is solving the problem. The fact we do it through the medium of code isn't that noteworthy.
If solving the problem requires knowledge from outside the domain of programming (Spoiler: it almost always does), then you learn what you need to from the relevant domain.
Software engineering requires understanding enough of the reason behind requirements to know when the requirements could be simplified or should be augmented. I would even argue that understanding business needs and translating them into practice is the fundamental role of software engineering.
This requirement might never have reached a software engineer in many organizations, and perhaps that's what I mean. So part of the mastery is ensuring you are around to provide solutions when business needs are being deliberated. That's fair.
An engineer's job is to solve a problem creatively, not execute a rote technical procedure. The people who are just fed detailed instructions to execute are called "technicians" in the traditional industries. If you want to claim the title of an engineer, act like one. If all you can do is write code to spec, you are a technician.
Your use of "spec" here is a weasel word to make your point. There are many kinds of specs. The spec here is "users need a physical copy", the organization was intending to solve it by using the services of another business and a bunch of other expensive and complicated stuff that I was considering as categorically different from software.
Business is not outside the domain of software engineering. "building the right thing" is more important in engineering than "building the thing correctly". If the proposed solution or problem to be solved misses the mark, most of the potential value has been lost, and excellent execution will not be able to recoup that.
Thank you for the story, I definitely understand now. I am also relieved that you were compensated for this critically important pivot! /s
I am hoping this will be an area I can eventually excel in. I was a senior PM for a while and decided I wanted to write code instead. Been going down this crazy career change for about 6 months now. Right now I am just trying to survive and learn the basics of software development.
When I was PM I certainly had the luxury of working with invaluable devs I could brainstorm with on ways to optimize a feature idea that maintained customer value in the shortest time possible. I need to learn how to become that invaluable dev I had.
I hope you are joking: “I, a paid employee, have a wonderful solution to our problem that will save the company a lot of money, but I won’t tell you if you don’t pay me even more.” I think the answer to that would be something like “hmm, if you aren’t willing to do your job for the salary we already pay you, I don’t think there’s any reason to pay you at all.”
This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer).
A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'
Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions.
Of course ideally everyone can contribute, but I think that's relatively rare.
If the structure of a work place is very strict, then yes this is 100% true.
I how ever could already experience a more open scrum process in which we all have a say.
For me it all started in an university project with four (incl me) people.
I denied a good portion of the requests my supervisor gave me there, not because they were bad, but because they simply did not fit into the time budget or were not realistic.
She was actually very happy about that because she was not that tech savy back then and learned a lot threw the process.
Very good experience for me and we finished the project on time and exceeded expectations.
> Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
Experience flips this equation around. The PM is creating the roadmap based on my input and expertise to decide what will be the most valuable use of resources. You move from construction worker to architect.
It's very easy to get distracted as a developer on something that adds little to no value. You will do this repeatedly throughout your career. Try not to :)
It may also depend how much you're micromanaged vs. picking your own path. Sounds like you're saying none of your work is self directed, and you don't participate in design decisions yet?
Anyway, even if you don't have much say there's still ways to direct your work. You can push back against whatever is demanding the low value work.
There are some teams that only work on high impact projects. If you feel that your current team is only doing work that's not valuable, you need to change teams or at least let your manager know to change your project. Ask for projects that you think will bring revenue to the company. Revenue = impact or increase in productivity of other engineers (this may involve writing an internal tool, etc.)
It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".
Absolutely. Touch typing is a game changer, not only because with practice, you can just think the code and see it appear on screen, but because you no longer have to glance at the keyboard and your full attention is on the code.
If I'm creating something from scratch or refactoring then a keyboard definitely gets in the way. Of course when I'm writing something from scratch I usually iterate a few times before I have code that I'm satisfied with, so going through those iterations requires a lot of moving things around.
If I'm solving a hard problem (i.e. architecting a system or coming up with an algorithm) then 99% of my time is spent thinking rather than typing.
Not writing from scratch, and not what I consider "nice" code (specifically avoiding the term "good" here). There are plenty of cases that wind up being typing jobs essentially. Usually, that means you're not really designing code as you write, though.
Depending on what I'm working on, just dumping stuff to an IDE buffer at 70WPM can be 10% or more of the time something takes. Which is enough that typing slower would have a noticeable impact.
Enabling the org to accomplish more with less (or keep it from falling into different pitfalls) is sexy.
I feel it's a core part of my job to keep the rest of the eng team happy and producing value. A lot of times this comes down to seeing problems as they arise (ideally before them, but it gets harder to convince management of future issues if they haven't manifested yet).
> the best ones can direct a whole team away from large swaths of work that is not valuable
Can't overstate how valuable this is. A team which can expose its members to this kind of leadership by example and direct collaboration will grow and outproduce teams which don't by an order of magnitude.
One has to be very careful in determining what work amounts to "value shipped". It's not uncommon to have a few persons who seem to ship all the value, while the rest.. just enable them to do so, by doing the required, but invisible stuff, like the refactoring required for the new feature to ship, or fixing the bugs that makes the customers not leave, or attend those meetings that has to be attended by someone. This is somewhat related to the 10x engineer story, sure, some are a lot better than others, but sometimes it's not entirely undue to their situation. Maybe it is a skill too, to be aggressive enough to grab the work that looks most valuable and push that through, leaving your team to do the rest.
(just unpacking) Prediction of value, initially and over time, requires market analysis.
Given that, predicting which projects will produce that value, and which designs will accommodate future additions of value, is engineering.
I still like Parnas's On the Criteria to Be Used in Decomposing Systems into Modules, where the choice of "information hiding" requires predicting what is likely to change - and predicting value.
They're totally different words. I used to be an engineering manager with direct reports who wasn't really much a leader. Today I'm an engineering leader without any direct reports.
Leadership happens from the front and doesn't really have anything at all to do with year end reports and making sure everyone shows up on time. Management rarely does more than HR busywork. The way many engineering mangers work they often have skills so outdated as to be effectively non-technical.
Leadership can happen at all levels regardless of title. Leaders often are some of the most skilled technicians, able to have an outsized impact on both the team and the direction.
I think that's an artificial split. Management is not only about HR busywork, it should also include all the things you've mentioned in the leader category.
Is it an official title? I keep seeing it everywhere now, everyone is a "leader." What exactly does it mean? Do you proclaim yourself a leader, is there some vote on it?
From my perspective it's completely meaningless and usually ego stroking.
Imagine an evaluation system based on this principle. It would be simple cost minus benefit, without regard to technical merit or project milestones or other silly process-based evaluation. This is the opposite of most companies. Generally promotions have to do with the size/cost of an employee’s piece of a project, not the benefit. Managers would be fighting to reduce their team sizes. I don’t know how you would back-propagate value though.
When I got bored with software engineering, I decided to invest in developing leadership skills and to try to build teams.
Many people (myself included) are motivated by the impact their career can have. The impact of a great leader is exponentially larger than that of a direct contributor (based on the number people they can typically influence, and the amount of resources at their disposal to pursue “bigger” ideas). A great engineer who is also a great leader will garner more respect from their team, and will be more effective than a great leader who was not a great engineer.
I’m currently a Director of Engineering, and have a goal of becoming a CEO. This is something I never remotely considered, and even scoffed at early in my career.
The transition has been difficult and exciting. I considered myself to be an excellent engineer, so transitioning to a role where the new challenge is how to convince other brilliant (but possibly less honed) technical minds to do things has been extremely fulfilling. It forces me to think harder about my habits as an engineer and why they are important and how I can communicate that — it also forces me to have humility and admit that some of my habits may not have been as good as some things other folks are doing. It’s been extremely fulfilling, and I’m much more excited about my future than I was during the last few years I was a software engineer.
How did you make the transition in the first place? My issue is that despite enjoying and having good leadership skills (based on external feedback so I'm reasonable sure that's not just my ego ) I'm not the strongest technically and getting into those roles seems to require becoming an extremely technically competent senior/principle engineer first.
I got bored with engineering because it became easy. The patterns always repeated, and I knew that the only thing standing between me and my desired outcome was a fully understood path of actions.
I don’t believe you have to reach this level across a wide domain, but you should be able to achieve it within some reasonably narrow technical scope. If you don’t, you will not be able to lead a technical team effectively. When you are in leadership, you may not always be on the hook for delivering, but you can win major support from your team if you are capable of diving in and doing something technically impressive from time to time. In addition, you will need to be able to teach engineers and guide technical implementation, which requires the ability to communicate clearly about deeply technical topics. I find that the less I know about a construct (think Law of Demeter, etc.) the less I’m able to communicate it to others or build solid arguments for or against it.
I think you must dig in and obsess about becoming great at engineering. My passion for this role is because of its meta nature. I love engineering and have built strong opinions about it over my career, and now I want to engineer a team of engineers who can see things similarly, and ultimately do greater things collectively. This wouldn’t be possible if I didn’t take the time to be a great engineer first.
Truthfully — the biggest thing has been leaning into my gut more as opposed to trying to reason through everything thoroughly. The decisions are many and the time is short. Kahneman’s “Thinking Fast and Slow” is a great read, and when working in engineering management, the conclusion to be drawn from it is that your gut (aka system 1) is actually really good at summing all of your past experience and telling you what you should do. There is definitely more in the domain of human psychology that I have studied as well.
In addition, I’ve been forced to continue to hone my technical skills, but more in the domain of “why” instead of “how”. I was able to be an effective engineer by mastering the “how” (which of course required some non-zero knowledge of “why”). However, the types of minds that exist in engineering (or at least the types I want on my team), are not satisfied with a boss telling them “how” to do something. The reasoning must be sound. Engineers want to see the work. If you can’t provide compelling arguments for why a new policy or decision exists, then you quickly lose credibility.
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”)
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.
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.
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.
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.
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.
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).
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?
re: HTML -- I've had strange requirements come in that required us to work around the HTML spec in order to get the UI to work they way they wanted. We eventually found a better solution...
but the point was that not all requirements are golden; sometimes the customer is plain wrong, ignorant, and stubborn.
Yes, I agree with that. It is not that customer is always right. But it is not that customer is always wrong either. We have to look at requirements, give them benefit of doubt, ask and listen to answers to figure out which are wrong.
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.
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.
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.
... 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.
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.
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).
> 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".
> 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.
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.
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
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).
>> “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.
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.
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.
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.
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.
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.
> 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.
>> 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.
> 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.
Never Split the Difference - Chriss Voss
Three Laws of Performance - Steve Zaffron
Peak - Anders Ericsson
All of these books fall into the category of rounding out my world view. I’m an engineer, and spent nearly 100% of 10-12 years of my life (school plus early career) focused solely on engineering topics. These books have made me drastically more effective at achieving personal and professional goals, especially ones that require cooperation of other people.