Trying to Convince People to Change (2016)
camilletalk.com
camilletalk.com
Being "around the block" is no excuse for not keeping up to date in your profession. True, software development has faster hype cycles than other professions such as medical or legal professions. However, just as experienced doctors need to keep up to date with standards of care, software developers also need to keep up with best practices.
The larger takeaway from this piece is that you don't need to read full books to understand latest developments. A developer that knows 10 programming languages does not need to read a 500 page book to learn their 11th language. But they should read one or two articles, and try a tutorial to get what they need from it.
Software development is a profession, and like every profession it's subject to constant change. Keeping your head down and ignoring new developments is simply malpractice.
I think the key phrase in the parents comment is "agile manifesto". If you've "been around the block" you can detect bullshit earlier, and know what new developments are worth looking at and which to ignore right from the start.
And to be honest, software development is full of irrational bullshit, both in big organizations, as well as "hipster startups". That's not a new thing, it's always been like that, most of the bullshit dies very quickly, but some sticks around for decades and does massive damage.
One of the most important skills of a senior dev is a well developed bullshit detector (while not becoming a cynic).
It seems that your gripe is mostly targeting "agile" and the related jargon. I remember clearly when the agile hype started and I was pretty disgusted by it ... just a bunch middle managers getting expensive certifications and inserting "process" that was getting in the way of productivity.
But I've come around. Developers have always been "agile" (although they didn't call it that), it's just that engineering management was not. Before, managers liked to create giant specs dictating everything and flow charts with unrealistic timelines. "Agile" really changed that. Now the more modern trend is small iterative improvements, and more direct contact between developers and customers.
If you view the agile hype as directed to engineers, it fails. But if you see it as enlightening engineering management, it far more palatable. Sure, engineers see "agile" as new words to describe the same thing they were already doing, but for many managers, it was something pretty new. Agile encouraged managers to get out of the way, and to allow developers to operate in the way they were most comfortable.
Maybe agile is over-hyped, but it's still a big and impressive development.
But even if you don't buy that, guess what, every engineer has an engineering manager managing them. If your manager is learning a bunch of new lingo and processes, it definitely behooves you to learn what they're learning before they do, to get in front of it.
My point is only to keep learning and staying abreast of industry developments. Even if they seem like BS to you, they may not to the people around you.
Also agile did not made managers go out of way. They have daily standups, sprints, tiny 4 hours long max tasks to track and and generally more day to day control and more ability to poison every single day instead of just some days.
There are plenty of good or irrelevant managers that poison nothing. But those who do are not minimize by agile at all.
Medical and legal are not having hype cycles that need to be kept up with in this way. They each have processes to test if a change is positive and then implement the change. For legal it is initially jurisdictional and not going with the change in the jurisdiction it happened is malpractice, yet not knowing the basics of New Orleans law in New York is normal.
> Keeping your head down and ignoring new developments is simply malpractice.
My general doctor knows nothing that is happening in the field of foot surgery (unless he injured his own foot.) Many of the complaints I see about people not keeping up is about people who are well aware of more alternatives and more details in the alternatives than the person complaining.
I was quite shocked at the seeming ignorance when my company selected new window environments or revision control a number of years back. But they all knew more about more than one via previous choices the company had used in the decades before than I knew about subversion and git or gnome and kde. Many of the details I assumed would be relevant to transitioning were never particularly relevant to them. Any of them learning too much about the choice not chosen was pretty irrelevant and could become negative if it developed into pointless complaining once the consensus occurred.
Medical and legal professions both have strong centralized authority. In the medical field, it's the professional organizations, in legal it's the judges, for architects there are safety and standards organizations. Software development doesn't have any such central authority, and the entire profession is also heavily influenced by biased business interests. So there's definitely a lot more BS and hype that floats around in software development.
That said, just because it's harder to keep up and filter the real from the BS in software development, doesn't give you a pass to ignore it.
Scientific literature does this all the time: they put forth a theory and evidence for it, and 5 years later write why they were wrong. But if the lesson is to not spend too much time on unreputable blog posts, I agree.
There is just a tendency to tell us we need to find the diamonds in the BS in topics that an average doctor or lawyer would ignore until an institutional change occurs after a consensus.
I work in the public sector where we both develop and buy software, and because of this I get to sit at both ends of the negotiation table. Agile dies the moment contract negotiations begin, because no one is actually going to give you money to start building a house and see how much you finish before you run out.
Maybe agile actually works somewhere in academia, a start up or deep inside giant tech, but it sure isn’t how most of us buy software. We setup requirements, detailed project plans, risk analysis and all those other things the agile manifesto tells you not to. Sure we’ll call it agile, but it’s agile in name only and by then we would probably have been better off if no one ever read the damn thing.
There's a pretty famous public sector counter example: the initial ObamaCare website. The initial site was contracted out using traditional waterfall development methodology and was a complete disaster. The rebuild was done with a far smaller team, at a far lower budget using agile methodologies.
Things move pretty slowly in government, and I entirely understand that the existing government processes with big lump sum payments and rigorous accountability are not very conducive to agile development. However, it's not impossible (as with ObamaCare, it has been done before). The next time you have control over these negotiations, maybe push a bit harder for a more agile approach and see if it works.
It's not a counterexample. Just because this method failed doesn't mean agile would have been better.
And GP wasn't saying that the alternative to agile is better. He was saying that in such environments, the key stakeholders do not agree with agile (regardless of what they claim). Their demands and actions demonstrate this. People will not provide money for funding without guarantees that agile says not to provide.
You have it right. We didn't explicitly follow the agile manifesto (or any other manifesto), but we did focus on shipping working software incrementally.
There are successor organizations, like Nava and US Digital Service, that have encoded principals and playbooks: https://playbook.cio.gov/
As for the waterfall in govt vs agile in commercial world, I think it's about difference in core principles - the govt is very much about accountability (being able to account for every dolar spend, not wasting taxpayers money no matter what), while businesses are ok with some waste as long as the end result is still worth it.
It's sad but true. Many government projects happily spend 2X or more just to know exactly where all that wasted money is going.
This is likely a result of the fact that taxation is mandatory, whereas investing in a company is not. If you are forced to pay for something, you're more likely to scrutinize how that money is being spent. If it's optional, there's a much greater degree of trust.
Imagine the demands: Have only founders, visionaries that code. That won't work and doesn't make sense.
It is perfectly fine to simple doing your job, however this "doing" has shifted. It is not about slavishly following specs, it is about feedback in complex situations. No need to be a prodigy, just give sufficient feedback.
And BTW: Camille Fournier wrote one of the best books on professionell development as a software engineer. It is called "The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change". This is golden.
My favorite is the lecture about sleep dept, about how two good nights sleep can reverse several days of sleep deprivation. Great. Work me 18-hours a day all week and leave it up to me to resolve it on the weekend. How convenient for the employer.
[1]: https://www.dol.gov/whd/regs/compliance/whdfs22.pdf
Schedule a workday to spend reading the book, or bill the company for taking up half your weekend.
If this worker is in a union, this is precisely the sort of issue to take up with the steward. Most programmers aren't, but apparently non-union workers already have an "an open and direct dialogue" with their managers, though it's kind of hard to tell if that's the case here since the manager is the one who can't seem to schedule one simple task for the employee.
If I found myself in this situation with a manager, I would ignore them to the degree possible and failing that, avoid them entirely, whatever that meant. Outside of a managerial context, I would just say something rude.
Moreover, there’s probably a lot of things employees want to change about their boss and yet, they never hand him a book. This leads to bosses thinking the problems are never them.
Influence, persuasion, and other forms of leadership rarely benefit from convincing.
How many psychologists does it take to change a lightbulb? Just one, but only if the lightbulb is willing to change.
"No matter how much a snake sheds skin. It's still a snake"
But behavior is not a skin, but the core, unless it is an act.
For instance, someone who is lazy won't become hard working. He can however, grow up by becoming more efficient and doing more with less work. Someone judgmental won't become tolerant, but his judgment will become more and more valuable.
IMHO, trying to change people is a lost cause. Take them for what they are and take advantage of their personality traits or let them go. And don't forget that diversity is not just about race and gender.
And I’ve never seen this work in the slightest. Just anecdotal info I know, but I do think its a general pattern.
If someone is disagreeing, and you ask them to “read a book to change their mind” you basically ask them to admit they are not right and that you have power over them. Two things that people don’t like in general.
And its pretty sad, because we are here in this civilization of ours mainly because of books. Ideas that survive generations and mold societies. And reading what someone else is really into is actually quite beneficial.
I personally try to at least skim through suggestions given from others, as its such an awesome tool to understand where someone is coming from. And would give you _much_ better leverage in any further interactions.
Even if its the fact that you’ve taken someone at their word to actually read something, you gain a “favor” in negotiating terms. And you would also know the language that the other person is thinking in.
Developers are very prone to “if everything else fails read the instructions” kind of thinking, and book suggestions are basically instructions for people. And I think the advice of being better off if you just try to read that works in both cases, even if it goes against our natures.
~Tao Te Ching
How many managers would be willing to go through the book and do the exercises? I don't know, not many :)
I like this blog post about this problem: https://www.yegor256.com/2018/10/09/can-you-control-us.html