Hacker News Reader

> We had backend devs doing frontend development with jQuery when we were using Vue.

I believe you, but I have so many questions. Where the devs prevented from chatting with each other before starting to hammer on the keyboard? Were the backend devs not curious when they had to import a new dependency (jquery in this case)? Who did the code review?

Having a backend dev do frontend is not different from a junior employee starting at the company. People have to support them, with advice, tips and reviews. Did the company failed at regular onboarding this bad too?

Honestly the whole thing sounds like malicious compliance. People didn't want to do a thing and they made sure it will be done badly.

Sounds like a very hostile environment. In my team we learn from each other and have fun doing so.

Some times managers do things to shake things up a bit. Some times they are right, some times they are wrong just like ordinary humans.

But what it takes to ruin the environment is not always a poor manager but just one stubborn grumpy senior dev who refuses to comply, and get some people along with him.

Having worked on both sides of the divide, I can say it's sadly common for back-end devs to underestimate the complexity of front-end development and discount the advice and opinions of their front-end colleagues. I've even seen scenarios where back-end devs were allowed to dictate standards to their front-end peers just because they had more seniority in the company.

I just had the same in the opposite direction (to an extreme degree, hand waving away an enormous amount of complexity). The blade of Dunning Kruger cuts both ways.

Though what you describe sounds awful too. Hopefully with the recent era of tooling and discipline on the frontend side, we'll see less of that.

Yes, that kind of arrogance can definitely come from the front-end side as well. I've just noticed a pattern with a certain type of back-end developer. Similar to the old XKCD physicist comic, there is a personality type that seems to think they can spitball an ad hoc solution to a problem that is better than the work of specialists in the field.

That training sounds absurd and forcing people switch roles for a sprint is worse.

That said, your example merely indicates that corporate workshops are bullshit. It does not contradict the value of T people.

In my experience, two highly specialised but disjoint people can only produce rubbish. This is where you need some entry-level intersection of knowledge.

In your case, I don’t expect a FE dev to care about persistence, nor a BE dev to worry about form validation. But both need to be aware of the customer, the business, and robust API design.

I'm not sure that's "T shaped" as much as it is "cross functional", which can be done without requiring anyone to know about anything outside their silo, as long as someone crosses silos and communicates. That's more of a systems engineering model, where a specific role forms the bridge and only the bridge, and specialists form the teams. It's a very Aerospace model of doing business.

Maybe we should call this U shaped people: Multiple specialisms.

For me, T shaped people know their speciality, but know enough of the surrounding context.

I've seen people write technically perfect but practically useless software, because the program didn't fit the business context. I've seen installation horrors where devs and infras took weeks to do a simple deployment, because they couldn't describe to each other what network config needed to be done or what was possible. And of course, the architects that used to be good devs but are now locked in an ivory tower and have no idea that their specs are unusable expensive dreams.

So for me, T shaped people can communicate to other people. They do their thing, but can explain how that thing fits in the whole. They can troubleshoot outside their part if the stack. The boundaries between specialities should be owned by multiple people instead of nobody, and T shaped people make this possible.

This mostly depends on the organization. If you have only access rights for a tiny sliver of the system, you can only be an expert. If technology swaps faster than your underwear, you can't specialize. If people don't get a chance to fail and grow, they won't become neither specialist nor generalist. So a T shaped course should be given to the CxOs and high level managers as they are the ones who can make it happen.

If you're part of a software factory and only turn a psd into a html/css website then yes, knowing a programming language and doing backend doesn't help. If you work at a company which sells expertise to others, then they will want you to be an expert at something.

If you work on a product team then it really helps to know a bit of everything, architecture, writing frontends, writing apis, databases, designing scalable services, managing hundreds of servers and other infra through automation, ci/cd, data engineering, ux, testing, talking to users, talking to stakeholders, gathering requirements, managing a project, managing yourself. From time to time you may ask the help of an expert.

Well if you interpret it as "do completely different jobs of different teams" of course it doesn't work.

It makes sense in single team context, say one person being very good at SQL but rest of the team having some basics will mean most of the "simple" tasks related to can be done by anyone instead of shoving everything onto expert.

Or say having just enough frontend skill that backend team can create their own internal admin panel for a service without involving frontend/UX in it and paying communication tax.

This comment is a classic example of misreading the philosophy behind T-Shape people. T-Shape or 'paint drip' people is a term used for generalists who have acquired a diverse skillset during their career and how these generalists have an upper hand over a specialist in certain domains. The book Range by David Epstein also goes deep into this philosophy.

A single anecdote of a misguided manager ruining it for their team does not invalidate the idea of T-Shaped people.

But T-Shaped people are specialists aren't they? That's the | part of the T. Specialists with enough curiosity and flexibility not to be afraid to go beyond their expertise and get a surface understanding of many other things that might indirectly enrich their core competency.

At least that's how I understand it.

Unlike generalists, they have gone through the tough process of going very deep into something. They understand that there's a lot of detail under the surface of any domain and they know how to get there when needed, whereas a generalists would disregard or be ignorant of any complexity.

I think T-shaped people are usually specialists-turned-generalists, for example good software developers who later on became managers. As a manager you have to be a generalist, and you usually have hundreds of small tasks, so no deep dive in one topic, but surface level in many.

In my experience these people are definitely better managers (unless they suffer of old physics prof disease), but I don't see the large benefits for more specialised roles. The more I switch to being a generalist, the less I can actually deep-focus, and talking to friends and colleagues, it doesn't seem like I'm the only one.

That said, interest and curiosity about other fields, especially the ones you actively work with or neighbour is probably always a great quality to have.

I'm here to bump the book Range but for me T-Shape theory is more about Tetris for Teams so you have overlap at the conversation level and enough depth in the direction(s) of travel. My hot take is Management Theory by 2D Shape Jargon is going to find its stride so in a few years xyzGPT will be classifying us as hyper-dimensional dodecahedrons anyway. /s.

People should at least read about 'paint drip' people https://www.linkedin.com/pulse/paint-drip-people-jack-many-t...

I'm not really clear if David Epstein merging the two ideas is the 'true' idea of T-Shaped people in the hive mind of the internet or not.

tldr: T-Shaped could include multiple specialties (which make it not look much like a T)

Ha, I had the exact same experience a bit over a decade ago! Only it came from a total misunderstanding of what agile teams were supposed to be, the idea that anybody on the team should pick up any story they wanted to.

So suddenly the graphic designer is writing HTML and CSS, the front-end developer starts writing SQL queries, and the product manager starts writing JavaScript.

The experiment lasted about a month with a lot of hurt feelings, because essentially all the code just had to be totally reverted.

The graphic designer knew how to write CSS for his browser and screen resolution, but didn't have the faintest idea how to deal with window resizing, browser quirks, unexpectedly long text, or how to integrate with our established frameworks at all. Just threw a lot of CSS straight into "style" fields instead of CSS files. The SQL queries fell apart in production because the front-end developer didn't know how indexes worked at all, or to aggregate values on the database server instead of client-side. While the PM's JavaScript was similarly just modifying the DOM directly instead of using the framework, leading to total spaghetti code (and global variables everywhere).

The worst part wasn't even the wasted time, but the damaged personal relationships. Because nobody had even the level of expertise to understand why their code had been reverted, so they blamed it on politics instead. The PM thought it was totally unreasonable to require usage of the framework, the front-end dev blamed the database architecture because indexes didn't seem like something anyone should have to deal with, and the graphic designer similarly could never be convinced of any good reason why CSS shouldn't be inlined into HTML. All of them wound up blaming the actual team member experts for getting jealous of their turf and trying to unjustly sabotage the new people's contributions.

Just a disaster all around.

Now obviously that was kind of a worst-case scenario. But nevertheless, ever since I've been extremely wary about people picking up development outside the area of expertise they were hired for, simply because people don't know what they don't know. In other words, they don't even ask to get assistance on how to do something properly, because they're totally unaware there's a proper way that's different from what they just naturally hack together.

This sounds to me like your team did not think about what it means work together.

Particularly now with so much technology support from remote working you can just keep an open channel. As soon as you get stuck or want to ask something, you just share your screen and ask for some help. Not much more difficult than that.

Well the team obviously wasn't thinking about a lot of things.

But it had nothing to do with an open channel. Everyone was literally sitting next to each other. But my point at the end was that it doesn't solve anything because nobody even thinks to ask in the first place.

This reads like nobody involved knows about code review and just commits straight to master. 'Hey this sql is fine but slap an index on name field' is not some shocking development if you just had three rounds of refactoring of a piece, let's say CSS. Or Java.

>It was your typical corporate training nonsense, a hour of watching videos, weird team activities including making animal noises with blindfolds on, playing with lego, etc

Tangent, but what is it with corporate teambuilding and this sort of games? I had to participate in one where people had to crawl on the floor, blindfolds on, while the "master" gave commands....... I mean come on, sounds like a fun evening, but in that context it left me quite uncomfortable.

It’s the usual hazing ritual, where the alpha manager gets to mark their territory.

I woukd quote our sexual misconduct document and leave the training.

> I think this is one of those things that makes sense in theory, but is kinda hard to implement within a corporate structure.

It was bad implementation clearly. You don't get to be generally good at different stuff without first being a lowish worker on each of those, having a person to hold your hand. You can't just declare that everybody should do anything after 2 hours of generic presentation and call it a day.

I spent most of my career until mid 2020 at small companies. I was “good enough” at pre-sales, writing SOWs, project management, designing and developing your typical enterprise online or analytics/ETL solution, “polyglot persistence”, “DevOps” at least if you gave me an empty AWS account and admin access, I could create your “Well Architected”, “12 factor architecture”, etc.

Fast forward to 2020, when I went from a 60 person startup to working at AWS in Professional Services where I do the same type of enterprisey things as a billable consultant, I realized that in most of those areas, there are plenty of people who can run circles around me.

But, my “specialty” is that I am a generalist and can go into your typical enterprise and talk to everyone in the organization from sales, to finance, to security, to developers, to the infrastructure people, etc and I’m self aware enough to know what I don’t know and know when I need to bring in a specialist.

I've found T shaped people are good for early startups, where you can have one person wearing multiple hats.

If you are large enough for corporate training events, chasing T shaped people probably isn't that important.

It’s valuable at the management level when dealing with cross-disciplinary teams. You don’t need to understand what any one individual function does to any real depth, but you need enough passing familiarity to ensure the team works well together and focuses on the right components.

> We had backend devs doing frontend development with jQuery when we were using Vue. Frontend devs started doing UX design and things looked like trash. QA was done by basically anyone so as you can imagine bugs started appearing everywhere.

Yikes, what a terrible take. To me, "T-shaped" people have at-least-minimal competence across a broad spectrum of the business. They don't do the work of other specialties, but they use their knowledge to avoid making excess work for those other specialties -- for instance, they make better-informed suggestions in brainstorming. Your backend devs know how the frontend stuff works, so they don't make tortuous APIs; they know how QA operates, so they plan for testability; they know the pitfalls of UX so they don't make rigid state-machines that punish users. And, if a disaster strikes and a team needs a helping hand in a pinch, maybe somebody with some depth outside of their role can pitch in. Making everybody do everything always is not T-shaped, it's, I dunno, #-shaped.

Someone becomes T-shaped because they’re interested in the things that would make them T-shaped in my opinion

I think it can be beneficial to show people where you can start learning a new subject but they have to choose to learn

that's what full stack developers are all about. You should do everything. From planning to deployment. From backend to web design. Tune your cluster and fix your CSS.

I can't tell how serious your reply is here. Is there a hint of sarcasm in there?

:)

That's what it is. You do scrum, you write your code, you do the work of 4 but earns as one.. and that's because its fun, t-shaped people don't like to stay in their comfort zone. /s