This is a good piece. Basically it is saying people aren't dumb. That person you are trying to get to read the agile manifesto isn't not reading it because they are lazy, stupid or arrogant. They've been around the block and know they don't need it. Also not everyone wants to be the top player, and apply a "growth mindset" and "can do attitude" to everything. They just want to be paid to code without unnecessary invented hassles. Let them.
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.
> This is a good piece. ... That person you are trying to get to read the agile manifesto isn't not reading it because they are lazy, stupid or arrogant. They've been around the block and know they don't need it.
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.
> Being "around the block" is no excuse for not keeping up to date in your profession.
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).
> I think the key phrase in the parents comment is "agile manifesto". ... One of the most important skills of a senior dev is a well developed bullshit detector
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.
> Being "around the block" is no excuse for not keeping up to date in your profession.
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.
> I work in the public sector where we both develop and buy software ... Agile dies the moment contract negotiations begin
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.
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/
>There's a pretty famous public sector counter example: the initial ObamaCare website.
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.
I've worked in government as well as multiple companies (from startups to huge multinationals). So, far only the government was adamant about speccing the requirements up front, waterfall-style. The commercial enterprises, even including an old and large bank, are much more open to agility and "not knowing exactly where the road takes us". Also, like you said, the government is much more into buying software - either COTS products or something tailor made to a spec - than developing it. It's mostly because the govt just cannot hire and retain good enough developers. The commercial side of the world is fine with developing in house, and most large companies have at least hundreds of developers on payroll.
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.
> That sounds like the government is all about accounting, not accountability.
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.
It's more than just accounting - everything needs to be pre-planned, there's no spontaineity or thinking as you go allowed. It's probably closer to medical devices software that to a typical BigCo web/backend software.
> True, software development has faster hype cycles than other professions such as medical or legal professions.
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 are not having hype cycles that need to be kept up with in this way.
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.
We have plenty of central authorities for the technical fields, for example IETF, IEEE, W3C all have systems for creating filtered papers and standards.. There is plenty to keep up with in applied CS that is the same as in medical and legal.
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.
Sure it does. Anyone can write a blog post about why you should do X, and then they write another blog post 5 years later about "Boy was I an idiot for suggesting X, do Y instead!"
> Anyone can write a blog post about why you should do X, and then they write another blog post 5 years later about "Boy was I an idiot for suggesting X, do Y instead!"
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.
Do managers give books as a work assignments and provide time/place to read the book. If you want an employee to "change the way they react to stress" giving them 8 hours of voluntary (but not really) homework probably doesn't help. If you want them to read it make it a required task and provide them work time, otherwise management/company is expecting the employee to give up personal/family time to read the book off the clock.
In the USA, at least, they aren't required to provide a time/place, but they would be required to compensate you for it, by the Fair Labor Standards Act [1]. It sounds exactly like "Lectures, Meetings and Training Programs", which means it qualifies as "working time". It's on the clock.
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.
I get this at my work. We get constant lectures about stress, sleep, healthy eating and such. Every one feels like the bosses trying to tell us how to spend our weekends. The last slide always has a series of references that we are expected to read on our own time.
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.
Is this appropriate behavior for managers? It seems not to me, but my experience is limited. It seems to me that "convincing someone to change" is inappropriate in just about, if not every, context and that being a manager doesn't make it more appropriate, it just makes the appropriate feedback (negative response, criticism) impossible.
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.
If someone had given her a book and askes her to read it and “change” would she? People always don’t understand why someone else can change while at the same time feeling frustrated at their own ability to change. Turns out change is hard and handing someone a book and calling it a say doesn’t really cut it.
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.
I had some troubles ages ago and one of my bosses hinted me to read the Siddharta by Herman Hesse. Today I wouldn't remember a single word about the book, but back then I liked it a lot although I experienced it from an atheist point of view.
Did it solve my problems? Not at all since most of them were caused by a PM in the same company whose assholery was right on par with his utter technical incompetence, but the suggestion by that boss may have helped afterwards; who knows...
My though entirely. People grow but fundamentally, they don't change.
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.
There is a beautiful and deep irony in that sibling comments here all read as closed to the possibility that their view on people's ability to change--whatever it may be--might be wrong.
I’v noticed this pattern with people in way more situations than just team member - manager. Spouses, friends, colleagues etc are prone to just “suggest reading a book” to solve an inter-personal problem.
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.
Imagine a software engineer giving his/her manager 'Learn python in 30 days' so that he/she isn't clueless in her 'agile meetings' when interacting with software developers.
How many managers would be willing to go through the book and do the exercises? I don't know, not many :)
You don't change people. You change the rules and they either adapt or find a better place with better and more suitable rulles. This is what freedom is about, and a good management.
