Very short article (which I like) and some great points that have been occupying my thought process lately.
Every other day our local newspapers mention the word "techy" to describe someone work in IT, he could be a product manager or an operations manager in facilities, just because he is in Silicon Valley of India.
The agile example is great. We enforced something which works for assembly line where things are repetitive and we know how much time it takes exactly to assemble two parts of a car. Software Development is could not be more different than this. We want iterative development yet we need to have
fixed deadline.
We don't trust the developer, we hire a scrum master who in most cases just moves stories in Jira if a developer forgets to do it religiously. In that process, we (read middle management ) are happy to have stories in "done" section but have a problem with "in progress" section tough later is likely to have higher quality. Because earlier one looks good on paper.
I have seen when scrum master/co-ordinators / middle managers when getting a tech-related question from other teams or execs, they loop the engineers saying "rookie question".Really just say "I don't know anything about engineering that my team does"
Also the "IC track" for engineers? Seriously if someone works in teams that is engineering teams. Why should they be called "Individual contributor"?
IMHO, if engineers were little more disciplined we did not need middle managers or these dedicated agile coaches, scrum masters who neither has any tech skill nor has any vision, unlike the leadership / executives.
The best of developers need a different breed of managers. These managers usually stay away from their path, shields the team from bureaucracy/clients and made sure they are aligned with the business goals.
I've been a prolific developer, a designer, and a manager. At the onset of my career, I didn't really care what the designers did. I took up designs as I saw the lack of all around. I married design into development. I've designed many digital products but have always coded them right in after the initial wireframes and the pen/paper prototypes.
Until about 2010, I tend to brush aside managers as stumbling blocks and just try to get things done. Well, I started leading a lot of high calibers, high performing developers and designers. They are way better than me. That when I realize a new way of helping them move 10x faster.
I try to bridge the gap between them and C-Suite stakeholders, clients and their tech teams. I can move between design, engineering, sales, marketing, and business discussions with relative ease. I've been thanked many times for blocking the onslaught of "requests" and meetings. That's when I knew that the best of engineers and designers can benefit from highly capable managers.
Wow. I'm not sure if this is even going to be a good suggestion. Let me try in a very personal way.
Having been a developer, designer helped a lot. I know what's going on and I can jump in. Unfortunately, I cannot jump in as much as I want to these days. Things do move fast and the best I can do is help in learning/researching a topic faster and help focus and save time.
While picking any consumption of information, I like to focus on the human side of it. I'm not trying to learn a new thing to either impress or even help them. They are way better than me when it comes to technology, frameworks etc. If I'm helping a newer or not so experienced developer or a designer, I already know how to help them without overwhelming them.
More than podcasts/audible, I read a lot (both physical and kindle). I avoid driving and take an Uber (I live in Bangalore and you know the traffic here) so I can read.
As for the few select podcasts - a16z, YCombinator, Startup School, Entrepreneur on Fire, Youpreneur, No Quit Living. I started being regular recently, so I'm still curating my choices.
Thinking like an entrepreneur really does help -- delegate, accept failures from one and all. Don't try to impress, or win anything. Try to be humble, modest and let others know that you don't know. Don't be that "Product Manager" that have never shipped a product, the "Project Manager" that has never designer/developed a project.
I hope you would be able to take some and form your own ways.
The scrum masters feel 100% like a scam to me. The "work" they do is a complete joke - they basically have a couple of rigid scripted behaviours that could be performed by a bot or an intern - ask people about tickets' statuses, ask if a ticket cannot be split into smaller ones, ask people to do estimates, ask if X can help Y on task Z etc (all these questions are so basic that in general any experienced dev has already asked them themselves in their heads before coming to a standup). Also, from what I'm seeing, they "work" maybe for 1-2 hours a day. The only redeeming factor is that they usually make way less than a senior dev (at least here in Europe).
I suspect Scrum Masters will be completely purged out of the industry in the next 10-20 years, as the execs realise they provide negative value (sadly, they'll probably be replaced by some other fad role, and the same people who are scrum masters now will just retrain into that fad).
The dedicated Scrum Masters I think already started to be diminishing, in my last two jobs usually one of the engineers (not too senior or junior but should be able to communicate well) is asked to take that role along with his usual 8 story point a week coding responsibility.
But unfortunately in this case above scripted behaviour is being shown by middle management (Engineering manager with not much coding background ). This is because they are mostly under fire if there is a "Spill Over" . The engineer playing scrum master role can easily get away with it because the probably did their part in the coding front and just threaten to step down from the role. But managers don't add much to anything else in the delivery process, so they are forced to be accountable for everything. (C'mmon we all know appraisals are also pretty much scripted) .
BTW I hope they make less than senior dev. My company is not much transparent about it. I hope there is a portal to anonymously share this information. The glassdoor and payscale figures are very wide ranged to get a ballpark figure and average looks way off (I am making unusually high :D )
World class athletes are highly disciplined and motivated (there is a difference between those two words btw). Yet you won't find a single one without a coach. Why? That's your homework.
One of the reasons developers will never garner even 1/3 of the respect of a surgeon is that our mistakes can almost always be fixed. If a surgeon makes a mistake, that can ruin a person's life or even end it. We have so much wealth that we can afford to devalue programmers and put up with bad code, but there's yet to be an affordable way to completely reverse a severed spinal cord for even the richest.
> There’s a destructive pattern inside of Agile software development of squashing individualism. Devs can’t be trusted to work solo, so pair them up. Devs can’t be trusted to think holistically about the problem at hand, so each 'story' needs to be written child-like. We demand TDD, a convoluted code-review and branch process, and antipatterns such as 'the big ball of mud' terrify us, so we must insist on nano-sized microservices to promote code shared ownership and polyglot diversity, so that each service can be rewritten at any time in any language, and no single developer can possibly ever become a bottleneck.
"It’s not simply the insidious dehumanisation and the patronising that bothers me - which to be fair, is a human condition - rather it’s the attempted commoditisation of what is a highly specialised trade. When you trivialise a trade, you make the trades-people interchangeable."
This pushback has been going on since the very earliest days of the attempts to professionalise software development. Here's Nathan Ensmenger in "The Computer Boys Take Over":
"In response to this perceived challenge to their authority, managers developed a number of interrelated responses intended to restore them to their proper role in the organizational hierarchy.
The first was to define programming as an activity, and by definition programmers as professionals, in such a way as to assign it and them a subordinate role as mere technicians or service staff workers. As the sociologists Haroun Jamous and Bernard Peloille argued in their groundbreaking study of the organizational politics of professional development, this technique of reducing the contributions of competing groups to the merely technical is a time-honored strategy for defending occupational and professional boundaries. We have already seen some of the ways in which the rhetoric of management literature reinforced the notion that computer specialists were self-interested, narrow technicians rather than future-minded, bottom-line-oriented good corporate citizens. “People close to the machine can also lose perspective,” maintained one computer programming “textbook” for managers. “Some of the most enthusiastic have an unfortunate knack of behaving as if the computer were a toy. The term ‘addictive’ comes to mind.”"
I think our society tends to offer respect and status to others for some specific (mostly superficial) reasons, and developers usually don't meet the criteria. I can think of a few different cases of this:
1. I feel society respects people with authority over others and most developers have none. Most of us are just implementing someone else's high level idea (granted, a great idea implemented poorly can be useless, so good developers are very important in fact. It just isn't clear to an outsider as to why).
2. We also respect others who have great social skills, but the word "coder" or "developer" tends to conjure up an image of some guy sitting behind a computer screen by himself for hours on end (if you knew nothing about what a software developer really does). Some devs will have good social skills, some will not, but I would imagine the average developer job does not necessarily require it.
3. The stakes matter. If a developer screws up, you revert the change or fix the bug and most of the time the worst case scenario is that the company lost some money (with some exceptions like those who work on self driving cars or autopilot). Doctors are dealing with peoples lives. Law enforcement, firefighters and military risk their own lives for others. Lawyers and high level executives at larger companies work in positions where the economic stakes are often high, not just occasionally.
4. We respect those who are at the top of their respective field. With software development, there is nothing that those at the top of the field are displaying to the public that differentiates them from anyone else in the field (that the average non developer can understand, anyway). This is very clear if you're an athlete or professional musician.
I would say that software developers as a group are usually fairly intelligent people with respect to technology. I think referring to someone as a "techie" does not make an assumption that someone isn't knowledgable about the domain of tech, but may come embedded with an assumption of lower status (with respect to the points I mentioned above).
As a developer myself, I do sometimes regret my choice given the low status that this job carries (at least in North America - perhaps in other parts of the world this is different) in spite of the fact I get paid fairly well. On the other hand, I enjoy writing code and solving difficult technical problems, so if I just forget about what people I don't know think about me, then the job is great. Hard to beat a comfortable, high paying job where I get to work on interesting problems and mostly get to avoid the annoying political battles that are often ongoing in large orgs.
Beancounters, suits and normies are the ones calling us techies. There is really no need to get upset about the labeling. Most of the time I see techies looking down on other departments at least as much as they look down on us.
x100. Let's stop using the inactive words "developer" or "engineer" to describe people.
Instead say things like we need to get some people to "build it" or "make it work" or "figure out what is the best". It is how managers obliterate their workers and claim all credit.
I like to use the word "human" in these cases to emphasize what is going on. "We need three developers" vs "We need three humans". The latter emphasizes how ridiculous and dehumanizing it is (unless you are a contractor and paid up front).
Managers are basically just schedulers at best. A good leader is someone who actually risks their time, reputation or capital.
Management structure would be fine if they were literally given a pot of money that they could pay themselves or contractors with and required to build something. Anything else involving employees kind of results in dehumanizing power structures once the size of the team gets big enough.
Every other day our local newspapers mention the word "techy" to describe someone work in IT, he could be a product manager or an operations manager in facilities, just because he is in Silicon Valley of India.
The agile example is great. We enforced something which works for assembly line where things are repetitive and we know how much time it takes exactly to assemble two parts of a car. Software Development is could not be more different than this. We want iterative development yet we need to have fixed deadline.
We don't trust the developer, we hire a scrum master who in most cases just moves stories in Jira if a developer forgets to do it religiously. In that process, we (read middle management ) are happy to have stories in "done" section but have a problem with "in progress" section tough later is likely to have higher quality. Because earlier one looks good on paper.
I have seen when scrum master/co-ordinators / middle managers when getting a tech-related question from other teams or execs, they loop the engineers saying "rookie question".Really just say "I don't know anything about engineering that my team does"
Also the "IC track" for engineers? Seriously if someone works in teams that is engineering teams. Why should they be called "Individual contributor"?
IMHO, if engineers were little more disciplined we did not need middle managers or these dedicated agile coaches, scrum masters who neither has any tech skill nor has any vision, unlike the leadership / executives.