42 ms·
This seems to be hallmark of a “Middle” developer. Not so junior that they couldn’t build a working solution that they assume everyone should use, but not senio
by sudhirj 5y ago
This seems to be hallmark of a “Middle” developer. Not so junior that they couldn’t build a working solution that they assume everyone should use, but not senior enough to think twice about whether they should be building it.
The “we should make a common framework” for this line is the dominant thought at this level. Never even a library. A framework. Everyone must do it this way.
The more senior people share concepts and maybe libraries, and allow the team to use them if they see fit.
- GiorgioG 5y agoI've worked at bigger companies and there are plenty of folks much higher than 'middle dev' forcing these types of things down the organization's throat.
- Fiahil 5y agoI agree. People use the most practical things at their disposal. If Tim had opted to publish a repository of easy and _simple_ recipes for managing kafka and postgres integrations, while retaining the ability to use original libraries, then I see no reason why it would not have gained traction.
- 1123581321 5y agoThis kind of consequential decision can happen at high levels. Obviously less often when a truly brilliant developer ends up in a small organization (but that has its own risks.) In the example, it was determined that they could not afford to let each service solve its individual bottlenecks ad hoc. So a corresponding strategic error was also made/forced at the senior business level. It's easy to speculate in hindsight, but in this case I could imagine a globally enforced throughput mandate supported by a widely visible and frequently reviewed dashboard, new tools/libraries as needed, and an optional central queue service required to 'compete for business' of the individual service teams. I can see potential problems with that too, though. In a sense, failure has already happened when growth management is deemed to be too important to be left to capable individuals on decentralized teams. Enjoyed the article.
- shuntress 5y agoIt's the large-scale version of taking "DRY" too literally. Junior devs just repeat themselves because they don't know better. Middle devs rush into an incomplete abstraction by overzealously not-repeating-themselves. Senior devs just repeat themselves because they know they don't understand what it would take to abstract out the solution. Like everything... "It Depends". Don't Repeat Yourself Too Much.
- deleted 5y ago[deleted]
- novembermike 5y agoOne thing to remember here is that a senior dev might be at the beginner stage for org wide changes.
- speed_spread 5y agoMaster devs avoid writing code at all costs. They've read Sun Tzu and understand that writing new code is just admitting defeat.
- chmod600 5y agoPart of the motivation behind DRY was to avoid the mess of repeating yourself within a task by updating 17 levels of classes and factories to add a field somewhere. This is mainly solved by using a sane language and not having useless intermediary code. But you are right: applying DRY between tasks requires good judgement, and sometimes it's best to just copy some similar code around than to prematurely invent an abstraction.