3 ms·
Yeah, I think that part of what makes a good engineer / good employee generally is the ability to recognise and work within the constraints of the organisation
by throwaway936482 6y ago
Yeah, I think that part of what makes a good engineer / good employee generally is the ability to recognise and work within the constraints of the organisation / team without spending all your time whingeing or proselytizing for the One True Way of doing x. This is quite difficult as developers as a breed have a tendency towards binary thinking and engaging in doctrinal disputes.
I actually agree that dependency sprawl / hell is a problem best avoided... which is why I avoid web development like the plague.
I think Rachel's broader point that the terms we use to describe developers / software engineers are very broad and sometimes unhelpful is right. I think she's being a snob in wanting to retain the high status term for what she does, while dismissing the stuff that she obviously struggles with as being not engineering, but I do think we shall take care to distinguish between high level engineering that largely consists of integrating existing libraries / modules etc. and lower level engineering that she engages in because they are different skills.
- ritchiea 6y agoSome of us even have jobs that are a mix of high and low level engineering and we have to have the good judgement to choose when to do one or the other.
- throwaway936482 6y agoNow that is a valuable skill.
- ritchiea 6y agoIt depends? Certainly for some companies but I wouldn't be the right fit if you need a highly specialized infrastructure person at Netflix or AWS or something. Sometimes it can feel like I'm only a good fit at startups which isn't great for earnings potential.
- jlokier 6y agoI think it's valuable in the sense that it creates value. It gets things built that work well, and fit into the bigger picture needed by the company. It might even be one of the essential skills in building a successful tech company. But I don't think it's valued much on the open market. As in, it's hard to be recognised for that kind of skill. Established, larger companies tend to have a structure in place and, at least on the open market, try to fit people into narrower roles. Even if there's a laundry list "tech stack", it's usually a narrow role. As ritchiea said, it can seem as if the only place where the range is a good fit is at early-stage startups, with plenty to do and good judgement needed, but limited earnings on offer.
- fractionalhare 6y agoWell said. This is exactly the crux of the problem. Sometimes it's appropriate to build in-house, and sometimes it's appropriate to glue together existing components. It really depends, and it's unproductive to pontificate about one being better than the other. I think the OP has a fair point about one mode of development being substantially different than the other, but I don't think it's appropriate to partition them into separate roles. Part of engineering is knowing which path forward is most appropriate under uncertainty, given information about the team's skillset composition, available resources and time constraints. A good software engineer is capable of holistically considering the options. If your third party library is considered like a paved road, this involves knowing when your vehicle can tolerate veering off the paved road, and knowing when you need to build a new road yourself.