4 ms·
I don't think the article is saying what you're describing at all, or at least, if it is then I missed it. As I understand it, the article is basically just cl
by MrJohz 4y ago
I don't think the article is saying what you're describing at all, or at least, if it is then I missed it.
As I understand it, the article is basically just claiming that to become an outstanding engineer, you can't just code what you're told to code, you need to understand why any particular feature is needed. Obviously that doesn't replace user research, project management, business leadership and strategy, or anything like that - no developer will also be an expert in all of those things, and a good business, like any team, has differentiated roles. But a strong developer understands what's going on in other places - they understand the overall business strategy, even if they wouldn't be able to come up with a strategy on their own; they understand how users are interacting with their product, even if they aren't doing the user research themselves, and so on.
I've worked with a number of developers for whom this sort of thing was a complete mystery - they could program very well, but if they were told one day to build one thing, and the next day to build the opposite, they'd just go away and do that, and never question why their instructions made no sense. Whereas a more senior developer would want to understand why they're getting contradictory instructions, and try and explore whether there's a non-contradictory solution.
- polote 4y agoWell here is the conclusion of the post > Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.
- MrJohz 4y agoSure, that seems pretty reasonable to me. Features themselves are broadly a software concern - software developers are in the unique position of being able to say what their code is capable of, and so it makes sense for them to be proposing features as solutions to the problems identified by other parts of the business. That's not to say that the development team should never accept feature suggestions from other places - when a user is very clear that they need a particular button, or the business team clear that they need a particular feature to compete in the market, then sure, that also makes sense. But I think the danger in software teams is less often that they only develop what they want, and more often that they only develop what they've been told to develop, and don't connect the dots. As an example, I worked on internal software for a manufacturing company, and they wanted various alerts to stop manufacturing in certain events. Meanwhile there was a communication tool being developed so that the manufacturing side of the business could talk more easily directly to sales. It was only from the development side that we were able to see how connected these two components actually were, and we ended up proposing a system where the alerts - which were almost always created by the sales/service team - would be built in to the messaging system. This made the whole thing much simpler for us to develop, but also simpler for the manufacturing and sales teams to use - rather than scattering features across the whole app, they lived in one place and worked more consistently. As I understood it, the point of the article is to say that developers should be trying to understand the world outside of their specific domain so that they can make those sorts of connections. Not because they're going to more right than anyone else, but because a team member that understands what's going on in the rest of the team will work better with the rest of the team.