Today I want to talk about bad engineers, and one aspect of them in particular - solution favouritism. But first, let me remind you again how engineering is supposed to work.
You get a problem - this could be anything - you might need a new database, a new frontend framework, a new package manager, or even more abstract, you might need a new way to show data to a user when it’s convenient for them. Heck, it could even be not software, you need water to come out of a tap, you need a new shower unit, you need a bridge to cross a river, you need to provide electricity to a remote region.
Then, you go deep on the problem. You look at the sub-problems, the unique constraints to this field, your company, your people and team, your future plans, your past plans, and much much more. These all matter.
From there, you try some solutions. You try each solution you can think of in turn, with small proof of concepts (POC) or experiments, and eventually you see what works best. You might rule some out because they’re not working well with your unique constraints. You might test others even further. This is where some knowledge of solutions can come in handy, but more on that later.
From there, you settle ties. If one solution seems pretty much the same as the other, you keep going. Find other unique constraints until a clear winner emerges. From there, you can go on to implement the solutions. If you find issues, then your POC wasn’t good enough, and you need to go back a step. It happens. It’s fine.
And that’s it, that's a (simplified) way to do solve problems as a good engineer.
Now, let’s talk about what bad engineering is.
Bad engineering is going into a problem solving phase with a bias towards your favourite potential solution. This is absolutely absurd yet it happens all the time, especially in software engineering and especially online. This is becoming too common online, and it’s super super sad to see. Let me list some phrases which I think are signs of bad engineering:
“We only use Swift now”
“I prefer Cocoapods instead of Carthage”
“You don’t use Typescript! LOL????”
“VS Code is the best text editor!”
“Oh, its Uber for ”
“You should use the architectural pattern for your next project”
“You can only scale if you have kafka in your stack”
“How can we use AI in this?”
"It’s X but using the blockchain”
“Lol you aren’t using ES2018?”
"Ha! You still use PHP?!”
I want to go even further than this. I want to say its bad engineering to even like a technology or tool. If you like it, you’ll have bias towards it when it comes to problem solving, and you’ll be a worse problem solver (aka engineer) for it. Sure, I find Swifts syntax pleasant, or readable, or maintainable. But at the end of the day, I’ll use it when it’s the best possible way to solve a problem. In the context of iOS apps, Swift can fairly lose to other possible solutions given the right constraints, from anything to Objective-C, to React Native, to a mobile website, to a better Google listing on Maps through to a simple flyer drop in a local area.
We are engineers. We solve problems. We don’t walk around with a box of solutions and contorting them into the problems we come across. We look at the unique constraints of the problem at hand and go from there.
"But Sam, I’m good at X and that’s why I like it, so I can do things faster and the business likes me for it”. That’s fine. It’s fine to be good at a particular tool or technology. BUT, it’s only a good solution if the constraints are correct. Some (common but not constant) constraints that might lean towards these situations are:
You already have a codebase of X, so you add more X (eg Ruby to a Ruby codebase)
Delivery date is near and/or cost must be kept low - so you emphasises your/your team current skill set in a search for a solution. As a good engineer, you warn management of the long term risks of not doing it the right way. See: startups.
The project is short term, such as for a tech demo, temporary use or similar.
So, in summary, there are a few key points I’d like to drive home and make clear.
Start with the problem. Work hard on dropping your biases, and evaluate fairly using good scientific and engineering principles.
Rule out stuff with pragmatism but keep an eye on those biases. But yeah, no need to write a front end framework in Cobol.
Watch out for blogs and online content selling solutions as a solution to your unique problem. It may be a solution, but I can guarantee it isn’t everyones solution. Some people on Dev.To are guilty of this! Myself included in past.
It’s fine to dive deep and master a technology, but the best engineers or developers don’t have a tool name in their title. Senior Java Developer sounds as ridiculous to me as Senior PVC Pipe Plumber. The best start with the problem and find the best solution for it.
Some blogs and online content focusing on a certain tool are usually there to make you more proficient in using them, but watch out for assertions you now know are intellectually dishonest and bad engineering.
Good luck with all this! The future will be amazing if we keep looking at problems and coming up with the best solutions. If we use what we have now going forward, we’ll stay pretty stuck. And we don’t want that.
Top comments (24)
Hi Sam, great post. Completely agree.
One additional problem I've also observed about tools is a desire to use the latest technologies just for the sake of it.
I'd personally much rather a well-architected, well-written solution in a slightly older stack than a hap-hazardly thrown together project in the latest tech.
Yup! Trying something because you read about it or saw it at a conference is fine on your own project, but suggesting its the best because the newest tends to be more wrong than not
Hey, good topic, I agree with almost everything what you said, but I'm not sure about this line:
"Senior Java Developer sounds as ridiculous..."
Every profession has specialists in a certain area, why not programming?
And, let's talk honestly, if you really agree with what you said, you shouldn't refer yourself as Software Engineer in iOS/Rails... :)
Lol! Fair fair, I tend to write that so people know why [on twitter] I follow them. At the moment i'm working on an iOS app adding more swift and objective C to it, so I write that. However, if a problem is best solved with a poster in our retail stores... I'll say that too! Open mind always.
Hi Sam, I agree with your article almost entirely. But I also think that quite often the constraint is precisely in the engineer knowledge. In the time that takes learning another technology. Usually the things we don't know surpass the things we know.
Thanks, and Yup! I think if you're constrained by time, its good to play to your strengths. But if not, or you know what you know isn't enough, it's time to study up! This is stressful, but never a waste of time :)
Your description of “engineering done right”, where engineers understand the whole of the problem in advance and evaluate multiple competing proofs-of-concept before starting the “real“ work, is the myth that brought us waterfall.
A major theme of evolution in software engineering over the last twenty years has been accepting that we don't understand the problem in advance (and in many circumstances can't understand the problem in advance); reimagining development as a process of iterating towards a better understanding of what we're trying to build, while we're building it.
The only thing more certain than us not really understanding the problem we're solving today, is that whatever problem we do solve today, we'll be solving a completely different one tomorrow. In this world, the idea of picking the “best tool for the job“ falls apart because we don't really know what the job is.
PHP looked like the right tool for Facebook up until it wasn't, and they had to write an entirely new language and runtime to replace it. Rails looked like the right tool for Twitter until it wasn't, and they had to sink years of development and lost feature momentum into replacing it.
I'd go as far as saying (in an idea parallel to Tom DeMarco's 2009 essay, Software Engineering: An Idea Whose Time Has Come and Gone?) that the more we can with any certainty decide in advance what the best tool for the job is for any given project, the less important that project is, and therefore the more likely the right choice for that project is whatever tool we know already.
So for important projects, the ones where we have to make decisions about how to solve problems we don't even know we have yet, it is our job as engineers to have an informed opinion about which technology and tools are just better for their general problem domain. The tools that will build upon the successes, and help us avoid the failures of the teams that came before us.
Certainly there are good and bad reasons to prefer one tool or another, and falling in love with some tool so much that you can not see its flaws is a too-common disease, but saying that having any preference at all is “bad engineering“ is an abdication of our responsibility to improve our craft.
Hey Charles, thansk for your awesome reply, some good points there.
You're right- what we're building is increasingly unknown in with agile software dev, and with startups and technology innovations in general. And your bank example is a classic story we've all heard too many times. However, I'd encourage readers not to just apply the above methodology not to whole projects, but any subtask, no matter how small. We do it all the time, Integer or Float here, Enum or String?, Right up to class, to package, to framework, to OS etc. I'd even argue (over a beer, my fingers only have so many key presses in them haha) that Agile looks like mini waterfall sometimes, and that's not necessarily a bad thing, agile is adaptable to the problem and the people.
I definitely think that my assertion of any preference is perhaps too strong of language, so I'll add some subtlety, I think it's strongly advised to proceed with caution when considering your preferences. Are they engineering reasons or other reasons. Engineering reasons are the best way of course :)
Thanks again for your time!
I love this point of view because I'm doing old javascript with var everywhere and I'm an adept of PHP so I'm forced to agree!
Using the right tool also depend on your environment, colleagues, skill and more... People are too judgy and elitist.
Yup!
I agree (who wouldn't) but in real life, especially in big corps, you cannot switch people like apples or oranges, so you do with the competencies you have at hand. Personnaly I'm not fond of Java but I have to manage java projects since that's all I have at disposal, I have to fight to even get other profiles like javascript or webdesigner as these guys pretend to be "fullstack" but in truth they cannot do CSS hackernoon.com/the-backendificatio... ;)
Sure, I think playing to a teams strengths is a valid factor in choosing a technology :)
I'd add some nuance here - If you have, for example, a jquery website, and you're making a tweak... then no need to rewrite it.
If you're looking to pick up an old project and add 3 years of dev to it with a large team... then yeah, moving to a framework (I wont say which, depends on the problem) might be a good idea.
Elixir is not a JS framework last time I checked haha. Although I'm sure someones written a JS transpiler, for some reason.
Another good approach! And yeah, I agree with this 'I understand that most of the problems can't be solve with my tools set. That's okay.'
Great post! Thanks for sharing this Sam.
It seems so simple when you read it like this, but so many struggle to break it down like this and not jump right in with a solution in mind.
Thanks Helen, I appreciate that :)
Yup... we're all guilty of it! But we gotta be better than that eh!
“How can we use AI in this?”
+1
LOL yup
or Blockchain :P
Or IOT