Just a Techie? – Techies, Devs, Boffins and Geeks

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.

Where are the malpractice suites for person info leaks of infrastructure downtime?

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.”"

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.

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.