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 engin...
For further actions, you may consider blocking this person and/or reporting abuse
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
Excellent article Sam! I look forward to your next one.
Thanks David!
More often than not, the bias is towards familiarity than favorites IMO
That's a good and subtle distinction, and an interesting one to unpack. I talked to it a little in the post, but ultimately, you need to be honest with yourself if the speed gained now using what you know is better than taking the time to learn something new that'll better solve the problem now and into the future :)