You’re right but i have always preferred people who can do a little more. Nothing against the socially awkward and conflict avoidant nature in many of these friends, but people who push back and fight to communicate their views and passions often got our team better outcomes than someone who just turns up and does the work they’re asked to do.
As long as it is not opposite set of skills (talks a lot without knowledge to back it up so essentially using charisma to convince people to do the wrong thing most of the time) then yes, a lil bit of negotiation can save you a whole lot of work in the long run (XY problems being one example)
For sure, I’ve been tricked into hiring those people before too. It’s good that there’s still something hard in running an organization, the whole “what is value?” question feels like it’ll be one of the few things we have to maintain work for humans over the next little while.
That is likely referring to what has become known as the standup, where developers read off the commit log for the "manager" who hasn't yet figured out how to use a computer.
It definitely happens at bloated organizations that aren’t really good at software development. I think it is especially more common in organizations where software is a cost center and business rules involve a specialized discipline that software developers wouldn’t typically have expertise in.
I have 13 years of professional experience, and I work in a small company (15 people). Apart from one or two weekly meetings, I mostly just work on stuff independently. I'm the solo developer for a number of projects ranging from embedded microcontrollers to distributed backend systems. There's very little handholding; it's more like requirements come in, and results come out.
I have been part of some social circles before but they were always centered around a common activity like a game, and once that activity went away, so did those connections.
As I started working on side hustles, it occurred to me that not having any kind of social network (not even social media accounts) may have added an additional level of difficulty.
It's not so hard if you're an expert in the field or concept they're asking the solution for, especially if you've already implemented it in the past, in some way, so know all the hidden requirements that they aren't even aware of. If you're in a senior position, in a small group, it's very possible you're the only one that can even reason about the solution, beyond some high level desires. I've worked in several teams with non-technical people/managers, where a good portion of the requirements must be ignored, with the biggest soft skill requirement being pretending they're ideas are reasonable.
It's also true if it's more technical than product based. I work in manufacturing R&D where a task might be "we need this robot, with this camera, to align to align to and touch this thing with this other thing within some um of error."
Software touches every industry of man. Your results may vary.
I've seen that plenty of times. I suspect that you haven't seen it because you live in a place with high cost of living, which induces a high turnover in personnel, or perhaps you've been working in very dynamic markets such as SaaS.
When I was starting my career in Europe as freelance sysadmin, I worked several times for small companies that were definitely not at the forefront of technology, were specialised in some small niche and pretty small (10-15 engineers), but all its engineers had been there for 10-20 years. They pretty well paid compared to the rest of the country, and within their niche (in one case microcontroller programming for industrial robots) they were world experts. They had no intention of moving to another city or another company, nor getting a promotion or learning a new trade. They were simply extremely good at what they were doing (which in the grand scheme of things was probably pretty obsolete technology), and whenever a new project came they could figure out the requirements and implement the product without much external input. The first time I met a "project manager" was when I started working for a US company.
>I worked several times for small companies that were definitely not at the forefront of technology, were specialised in some small niche and pretty small (10-15 engineers), but all its engineers had been there for 10-20 years. They pretty well paid compared to the rest of the country
This isn't possible in the USA. Companies like this (small, and not in tech hub cities) always try to take advantage of their location and pay peanuts, with the excuse "the cost of living is lower here!", even though it's not that much lower (and not as low as they think), and everything besides houses costs the same nationwide.
I agree that something like that is very unlikely in the US, which is why so many people in this thread (I presume Americans) were incredulous as to whether that was even possible, but elsewhere in Europe good software and electronic/electrical engineers can be making very good money for the local standards in stable jobs, while at the same time being paid a lot less than they would be in a similar job in one of the US major tech hubs.
I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech company. Other than at the new grad level but it's treated as net-negative training while they learn how to build consensus and scope out work.
Not coincidentally, the places I've seen this approach to work are the same places that have hired me as a consultant to bring an effective team to build something high priority or fix a dumpster fire.
A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way.
I originally hoped it was growing pains, but I see more and more fundamental flaws.
I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out).
Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
Previously? There was an understanding of the problem trying to be solved. The gaps left the pangs of "this isn't right".
Now I have no way to know where things stand. It's all disconnected and abstracted. The ticket may suggest that something is done, but if the customer isn't happy, it isn't actually. Worse, now we have people adding tickets without any intent to do the work themselves and there isn't a great way to determine if they're just making up random work, which is something that definitely happens sometimes, or if it truly reflects on what the customer needs.
You might say that isn't technically a problem with ticketing itself, and I would agree. The problems are really with what came with the ticketing. But what would you need tickets for other than to try and eliminate the customer from the picture? If you understand the problem alongside the customer, you know what needs to be done just as you know when you need to eat lunch. Do you create 'lunchtime' tickets for yourself? I've personally never found the need.
You must be working in projects with a relatively small number of “problems to be solved” at any given time, and with the problems having relatively low complexity. In general there’s no way to keep everything in your head and not organize and track things across the team. That doesn’t mean that a lot of communication doesn’t still have to happen within the team and with the customers. Tickets don’t replace communication. But you have to write down the results of the communication, and the progress on tasks and issues that may span weeks or months.
I find that the current way we do Scrum is way more waterfall-ish than what we had before. Managers just walked around and talked, and knew what each person was doing.
We traded properly working on problems for the Kafkaesque nightmare of modern development.
I've realized it's a different paradigm in (very loosely) the Kuhn sense. You wouldn't track tasks if you're fundamentally not even thinking of the work in terms of tasks! (You might still want a bug tracker to track reported bugs, but it's a bug tracker, not a work tracker.)
What you actually do is going to depend on the kind of project you're working on and the people you're working with. But it mostly boils down to just talking to people. You can get a lot done even at scale just by talking to people.
People gotta remember its a job just like anything else. I dont see any other profession going above and beyond so why should that be levied upon on programmers, I don't see PMs trying to understand code, CEOs trying to understand the customer more than the investor.