'Treat your developers like creative workers – or watch them leave' Twilio CEO Jeff Lawson believes companies should let their software developers off leash. "Writing code is a creative endeavor, and not a lot of companies fully understand that," said Lawson in an interview with The Register. "A lot of people think of developers as math nerds who want sit in a corner, eat Doritos, and be told …
Many times in the past people have told me the solution they want me to implement to fix the symptom of something they don't like.
I have had to say to them "what is your actual problem?". Very often there was an easier way to solve their problem by standing back and seeing the whole picture. Many people have a tendency to implement "blister" solutions that merely add another short-sighted link to an already complex chain.
I tell people that as a BA, my job is to pester the hell out of the business by acting like a toddler; just ask "Why?" over and over.
Nothing bothers me more than being handed a "requirement" that says, "I want a new checkbox on this screen that someone has to tick in order to click submit." Besides possibly being bad UX something that isn't typically part of the UI, there is an underlying issue there that isn't being properly voiced. Did Legal come by and say this action requires a second confirmation before it can be completed? Is the Call Center fed up with people calling in to rescind an action they took? Perhaps Operations is tired of some orders being incomplete.
All of these are legitimate business problems and need to be resolved. But the problem more often than not is the person requesting is a SME in that particular flow or function, but doesn't know how it fits in the larger picture. So I sit down with them and figure out what's really going on, what really needs to be resolved, then I get with my developer(s) and we talk about proposed solutions.
To be fair, I've worked with a few Devs who just want to be told what to do. They can't stomach JADs or other solution sessions, don't want to spend time in a meeting with a few other people tossing around ideas, etc. But I've found that even the most adamant "just tell me what to do" Devs like to have input at some point, even if only to say that they think the checkbox should be a radio button, and give a reason or two why.
If a BA asked me "why?" too many times I'd consider that they might not have that good a handle on the B part of BA. A good BA should be able to quickly work out what the business user is after or what solution is required by virtue of their knowledge of the business. If they have to ask too many questions then they're just a minute-taker dressed in BA clothing that is likely just adding Chinese Whispers to the message chain. Just sayin'.
If a BA asked me "why?" too many times I'd consider that they might not have that good a handle on the B part of BA.
The funny thing about being a BA is that we don't often get to spend a lot of time in an area to become SMEs ourselves. One very large company I worked for actually redesigned their analysis and design process with the explicit goal of eliminating the need for BAs to have any kind of knowledge of the business or technology that ran it. They wanted BAs to be mobile and experts in elicitation rather than flow. They wanted BAs to ask why until people went crazy, and even provided training on how to do it.
I'm being a bit glib, but the reality is that in a technology department, an hour of BA time is less than an architect's, and even a quick code change often requires 2-3 hours of time after factoring in Dev, QA, UAT, and such. So if I spend two hours pestering the business and end up coming up with a non-technical solution, or a technical solution that can be implemented more quickly than the original "requirement," I'm doing my job.
Plus, I just don't like people.
Oh I agree with you and the ideas behind this article.
However... we 're in an industry where anyone can say they know how to code.
You can give them 'coding tests' and of course they've crammed for those and can pass.
Yet when you try to give them real work... oooh boy. Time for either a couple of aspirin or a shot from the flask.
Look at it this way. Everyone wants a chef in their kitchen, yet they are paying low wages for classically trained chefs, and end up with line cooks who think that they are chefs and are willing to work for said salary.
If you don't like cooking ...
Think about walking in to a pharmacy where you need the pharmacist to mix a compound for you, and you end up talking to a pharmacy assistant who only knows how to open bottles and count pills. (Yes, there are some pills still made on site, and that's old school pharmacy. )
As a developer, I used to be given a nice chunk of work, such as "Add Facebook to our device", and I would go away and research it, talk to customers, plan it, implement it, get it tested, deliver it.
Then came Agile.
Now UX design a project and we have loads of meetings and I get given a task to "Make this button start a Facebook connection", "Make this area show the users friends", "Line up the borders here".
Everything takes longer, for more people, and - more importantly for me - it isn't fun any more.
Everything takes longer, for more people, and - more importantly for me - it isn't fun any more.
But the PHB's and MBA's love it because they can micromanage everything. One so called manager I encountered wanted to know why I didn't ask his permission to stop my current task and deal with a P1 problem at a customer. At the time, said manager was skiving off down the Gold Course with his other managemt pals. Higher ups thought that they were doing some brainstorming.
Agile was one of the main reasons I took early retirement. I got pissed off with the rigidity of a supposedly flexible (As in agile) methodology. As for SCRUM.... [expletive deleted]
Scrap the lot and watch the productivity go up and along with it employee job satisfaction.
Just my worthless opinion though.
What's in a name? A recent Computing survey asked if I'd used Agile or Waterfall methods in the last project. "Agile" sounds great to PHBs, involving the opinion of others, and therefore 'a good thing' whereas "Waterfall" sounds like top-down overloading of things, dictatorial, and by default 'a bad thing'. It's like the creators of the Agile system have never heard of 'designed by committee'.
If Agile had been called "Stuck In Meetings" instead, it might not have been as popular.
I read a very good article on using Agile for a distributed system.
All the developers ran down the 'happy path' i.e. they got to chose the nice test paths.
They spent 80% of the time doing the easiest 20% of the project, leaving the hard 80% of time/20% of work for another methodology/team.
The worse thing is when you get a highly specified request, do it, then get another request a few weeks later to patch the same area of code because the first request didn't consider everything.
You are unable to do a proper job, and in this trade it's all about job satisfaction in doing something properly because that's really what it's all about. Agile has finally managed to take that away from us.
The worse thing is when you get a highly specified request, do it, then get another request a few weeks later to patch the same area of code because the first request didn't consider everything.
To be fair, it is pretty hard to consider everything at design time. Something always gets missed or isn't apparent until people start using the solution in anger. That's why a shorter, more iterative, development cycle can yield better results in certain industries. It's when the method of operation becomes overly prescriptive (Agile, Waterfall) that shit falls down. You just need to apply a bit of intelligence.
I work on trading desks prototyping solutions for strategies and the model is fast moving and iterative but, to be fair, the work is often lone individual (development side) working with trader rather than a team of developers.
The sad part is the real idea behind Agile was an attitude to break down the silos between groups and empower developers and users to actually talk to each other about problems and solutions. The idea is they would have relatively frequent meetings with whoever was needed to keep the project on track. It has been perverted by PHBs and MBAs (and even lower life form) to something else. Uncle Bob Martin has a few choice words about the perversion.
Where I work, it is expected that end users and programmers will talk to each other as needed as the project moves forward. The purpose of Agile but the formalism normally used.
[Fr]Agile makes certain management types happy with themselves for implementing it, and gives "the most junior guy" plenty of say-so in implementing the "solution".
<sarcasm>What's not to love?</sarcasm>
Which of course is a recipe for FAIL unless said management type is genre-savvy enough to prevent it.
(in such a case, genre-savviness, he would've had been TOLD TO USE AGILE by a higher level management type, rather than 'swallowed the koolaid' or 'thought that one up himself')
Once business get beyond doing grunt labour, like digging holes in the road, people and their skills and knowledge become less + less fungible.
Not that most orgs of the last 20 odd years have learned any of that, as I arrive and look at steaming piles of sh1t with noone around to actually do the work.
>The Rapid Response Toolkit
Thats great until you realise the communication infrastructure delivering net access and cellular comms is in crisis, as the US found out after Hurricane Katrina. https://en.wikipedia.org/wiki/Criticism_of_government_response_to_Hurricane_Katrina
Whats not mentioned in the link, is the telco's didnt get generators to keep the cell tower's running for extended periods of time, so many generators ran out of fuel after 48hrs.
Fortunately some new standards in wireless comms should make it possible for future mobile phones & other devices to communicate in a distributed evolving over the landscape based on needs mesh network for large scale crisis thats affected normal infrastructure, or for area's like mountains, desert's, wilds of Africa, South America or Russia where normal infrastructure simply doesnt exist.
https://en.wikipedia.org/wiki/IEEE_802.11af#Comparison_with_802.22
Moving aside from the article's main point a bit ... I dont get this posh chairs, wacky work place wank.
If you want me to work for your company then pay me loads.
Dont bother with free food. Pay me more and Ill buy my own food.
Just give me an adjustable chair + desk. A few decent systems and proper backup server.
All this wacky Richard Branson 'We're so cool. Im wearing a dress! (Dont look at the salary)' drives me nuts.
It comes down to supply and demand. For various reasons, there are few people out their with lots of software skills. There is currently a lot of demand - some proper profit, some gnomes underpants.
I'll preface this reply by saying that I consider myself a "creative" person, and a "people" person, but:
I hate "cool" offices. They remind me of really good mental health facilities. Outwardly pleasant and cheery, but only to compensate for the fact that nobody who is there really wants to be there.
I tend to agree with "pay me more money" but for I'd express it as "let me work shorter hours".
I also don't want free food or soft-drinks - for me, as for many other people, eating is a stress response, and sitting at a desk for long hours to meet a contrived deadline is already bad enough for my health without adding excessive salt, fat and sugar consumption to the mix. Again, I'd prefer to work somewhere where there's good enough management to ensure that going home after eight hours is the norm, with very low deviation from that.
As for furniture, I actually love designer furniture ... in houses, or hotels, or bars, but I really don't need it at work. However, ergonomics is much more important and often forgotten completely in the rush to make a visual impact. I've seen lots of places with "cool" furniture that cannot adapt properly to very short or very tall people sitting at the desk. A pretty office space might be good for morale, but back-pain outweighs it, I'm afraid.
Also, I don't see any problem with people of either sex wearing dresses in work provided that it's what they feel comfortable wearing : a good workplace is one where nobody feels like they're unwelcome, and again that has nothing to do with graffiti-art commissions, in-house massage therapy or Nerf guns (save me from grown men playing with children's toys...).
Too many start-ups adopt a "cargo cult" approach to offices - trying to reproduce the superficial props that they see in good places to work, without realising that those are the (often self-funded) result of employees who enjoy coming to work, not the cause.
The food and drink thing always get me.
I sort of expect on tap tea or coffee - Ill make it myself!
But the cool places tend to have pop and muffins. Ive seen one provide fruit.
The days of an office canteen are way over. I only worked in one place, 30 years ago, that had a canteen.
"The days of an office canteen are way over. I only worked in one place, 30 years ago, that had a canteen."
My employer has staff canteens at its major sites. They were outsourced, of course, initially to a firm that happened to be owned by a member of the board. Part of the contract stated that "self-making facilities" (kettles, microwaves and fridges to the rest of us) would not be permitted on sites with canteens, ostensibly for health and safety reasons, but hidden in the small print was the admission that it was to maximise profit opportunity. Why would you pay the exorbitant canteen prices if you can make your own?
Unless the question is "What is the point in spending 10 or more years of your like studying software engineering".
Trying to maintain other people spreadsheets in a meaningful way means you never take easy shortcuts that you know will become locked into the system and require you to maintain it - probably on a friday end of month when you are on a promise. I've spent many a long hour writing vb libraries so the accountant can write 'maintainable' code in a spreadsheet ( i.e. call the bloody library routine). Mind you you need a slightly* above average accountant to do this.
*in an exponential way.
Couldn't agree more with the Twilios attitude and the above posts about agile.
Producing software is a combination of knowledge and fluency in the tools plus creativity in the design and actual code of the solution produced. As such I prefer to think of software developers as skilled tradesmen like plumbers, electricians etc.
The real quality of the work we do can only be fully appreciated by a fellow tradesmen, In our case we can get Kudos points for elegance of algorithm, keyboard speeds,readability of code, performance of the apps..
I'm not too keen on the term 'professional' as it so often misused to upbraid status like adding the word manager to a job title.
So let's revive the titles tradesman\woman or journeyman\woman to genuinely raise the status of capable experienced people who might ot have a formal traingin but are still vital assets to companies.
At one point in my career my company made the decision to vary the title of "Consultant" with the alternative of "Consultant Practitioner". The latter title distinguished those with the depth of experience to actually roll up their sleeves and fix the customer's problems.
The difference between a "crafts(wo)man" and a "professional" could be said to be - that the former is often a gifted "amateur" who will deliver a working solution even if the money runs out.
-- of working creatively. And many personality types working in the field.
So it would seem, again IMHO, that any one-view workplace recommendation will have exceptions; the more tightly the view is focused the larger the portion of the personality bell-curve(s) which will fall outside the recommendation.
I'm very biased toward the solitary-creative side; my boss is a seeker of consensus and cooperation. Probably a good workplace mix, but of course I get impatient and even cheesed off sometimes because it can take so damned long to group-talk something I could have already had finished.
Point being -- I agree with the above comments. And I have to admit other points of view are valid for other work styles as well. World != single theory. Blast. Would be so much simpler...
Along with 'Decline and Fall of the American Programmer' by Ed Yourdon.
Constant re-examinations of current models of software production and their percieved problems followed by suggested solutions (which the advocates then take on world seminar tours).
Personally I'd like to see a serious in depth study on the 'science' of budgeting. How come it's always the project that comes in late and overbudget, and never the Budget that was badly specified in the first place.? With the usual consequence that the infantry get fired, and the budgeteers move on to the next project.
"How come it's always the project that comes in late and overbudget, and never the Budget that was badly specified in the first place.? "
Part of the trouble is that the errors only have one sign: there are very few mistakes that cause a project to take less time. Compare that with estimating a length, where you can undershoot as often as you overshoot. (And cost is a function of time.)
I have a few statistical workarounds for this. But they produce estimates nobody wants to hear.
I agree that leaving coders room to be creative by setting them free to do design and implementation is a good idea - once they've proven that they are capable of doing so. This needs experienced technical leaders who can gfive guifdance through reviewing code and getting everyone to follow the same basic rules (Huge manuals of coding rules and standards are inefficient and unhenforceable in practice). This prevents creativity being misinterpreted as "do whatever you want, any way you want" and produces a good enough standardisation of codiing style, documentation, etc. It does however give the developers a lot of i nterestring chances to be creative by gvng them responsibility, as long as the seniors understand that their role is not a "no, you must do it the way I would havfe done it" one.
Just letting the kids loose in the playpen is as bad as attemptting to use Scrum to micromanage development. Using the good parts of the agile philosophy like refactoring or only coding for what is currently required is a good idea. However these ideas have been around a lot loonger than the agile manifesto.
"only coding for what is currently required"
Not necessarily a good idea. I've been effectively instructed to code myself into a corner with that approach.
I then watched them having to hack database and code every time a new requirement was added. In the meantime I'd set up the next project which started off by chucking out all the "currently required" code of the first project and replacing it with an open-ended approach that took new requirements in its stride - including being re-used in the project after that.
However, have an upvote for the rest of the post.
"only coding for what is currently required"
There can still be the option to leave the approach open-ended whenever there is a possibility. However - micro-managers won't even permit that possibility - then complain when the cost of a modification involves extensive reworking.
"only coding for what is currently required"
I remember someone giving a lecture about 30 years ago on their successful use of C++ to implement a checkout (POS) terminal. They said that it was only possible because they had already spent many years in previous developments discovering the vagaries of customer requirements in cross-border, multi-currency, multi-vat rate retail businesses.
They were therefore able to construct their object architecture to cover the possibilities. Otherwise it would apparently have been a tear-down every time when someone came up with a new wrinkle they wanted.
"once they've proven that they are capable of doing so."
we're back to what I see as the major weakness in [Fr]Agile: the junior guy gets to have his say-so in the design, presumably on an equal level to the most experienced and/or knowledgeable developers.
I have been in meetings where this happens, and seen the results of meetings I have ALSO deliberately NOT been part of a project, one that had meetings where that apparently happens, and it's frighteningly ugly - project I had working in 3-4 weeks as a demo takes OVER A YEAR, never completes, and then in conjunction with a round of layoffs, I'm brought in and tasked with, along with another senior developer, getting it finished up within a month. In other words, that entire year went by with moving targets and the manager going into a squee-fest with the junior guy over the endless possibilities, or so I've been told, and manager ends up going with a LOT of different ideas that should NEVER have been gone with.
Some people think that pitting one engineer against another for "competing ideas" is a GOOD thing. I think it's EXTREMELY BONEHEADED, and is only likely to result in rage-quits and self-stifling in "go ahead, do it YOUR way, see what happens" mode. Some 'not so competent' engineers are REALLY GOOD at sounding like they know what they're doing, only to find later on, that the thing just doesn't work, or never gets finished, doing it "that way". Yeah, OOPS.
And it seems to ME that [Fr]Agile _ENCOURAGES_ this.
meanwhile, in light of all of THAT, the saner approach of "every developer gets to have his own sandbox with a set of well-defined requirements" makes even MORE sense, now. The boss, naturally, would have to know his employees, monitor them occasionally, and make sure they're on track, to make THAT work...
as you then get high demand for everything instant.
"Oh we need 100 containers because
Then you spend the night firefighting because the dev's decided to push what they want live. *AGILE YEH YEH YEH!* :/
so now, you've got to implement some sort of automation, but no chef isn't the new craze and so it's now puppet. But puppet is now old so you have to whack ansible. So my job of fixing backups, ensuring something isn't broken and jacking off in the bathroom to relief stress is now taken up by writing a recipe book when my PXE setup is just fine. FML
Environments like that suck. I'm all for chillax environment, open windows, breathing spaces but working in environments where dev's are let off their leashes. its a PITA for other people.Without sys-admin you would have no dev.
Don't let me get started on letting dev's become sys-devs. "Lets run ubuntu!! with no firewall, live off some PC thats hooked to the network under the desk with no prior authorization".
Also such gimmicks as such as the Tardis are just embarrassing.
"Don't let me get started on letting dev's become sys-devs."
Back in the day we were the (very small) Unix/DB team. Design, develop and manage. That way you didn't develop what you couldn't run and you understood the application level consequences of what you did as an administrator.
Yes, it harks back to the idea that if you were a Unix user you were a C programmer. It might have its downside but has the situation where you had to write a stack of documents to have the system guys release a slab of storage space for the DBAs to add as a chunk to the database engine, a process that seemed to occupy most of the 4 weeks I spent as holiday cover there.
Programming is both art and science. After one masters the basics, it really an art to find the best solution to the desired result using the most efficient and stable code. Bumming code is a lost art.
But treating programmers well would mean companies would have to throw out their most cherished and sacrosanct business philosophy: code monkeys for cheap and fuck the customer.
You master the syntax which, language depending will take you 6 months (C), never (C++ - moving target).
Then you master where the language fkcups - 5 years.
Then'll you master how other people can fckup an implementation with a language - never.
Then'll you have Zen like lightbulb moment as you realise building any non trivial code base with anything but Makefile/cmdline, where you can archive the build options, build files, tools versions etc etc, is insane. You will then look around he office and see everyone using IDE's where not a single configuraion matches another...
These comments are basically validating how I've been feeling this last 5 years as we "transition to agile" where I work.
I chose programming because I enjoy solving problems, fixing things, learning how things work and applying that in a practical way. I like helping people.
But my role has been changing though, I don't like meetings but my days are filling up with them. These are to plan the work I'm not getting time to do, basically because of planning meetings. There are then retrospectives, "social events" like hackathons and team building, as well as company enforced "10% time" - that you actually get penalised in reviews if you're not doing.
All these things steal time from actually building things, doing work, talking to customers, learning the application area more. My productivity has gone down, not up. I'm having to work longer hours to catch up so I see my kids less. Work from home has now gone, so we can all attend 15 minute catch up meetings in the morning, that end up being 45 minutes minimum.
My jobs gone from interesting and fun to boring, and not fun.
I just want a job that:
1 - pays well
2 - treats me like an adult
3 - gives me interesting problems to solve
4 - limits the amount of meetings / corp bs I have to be involved in
Bonus points for:
1 - 1 or more work from home days, and flexitime
2 - decent tools (no cheaping out on the licenses, machines)
3 - lets you fix what's wrong with current products (house keeping, bug fixing, listening to customer complaints).
4 - allows you to move around internally, if you grow bored/frustrated with a technology/product and they have options
I'm changing jobs soon, the new place seems to tick the boxes above... fingers crossed.
But your agile scum master knows what is better ! We don't need design docs -- just keep grinding away until it passes CI/CD smoke test ! We can re-do NEXT TIME . . if you don't follow the group cult culture you will be viewed as a undesirable and not a team player
I hate agile .
decades ago I worked in the M.I.S. department at a major corporation. They brought me in because they had a stack of work requests that weren't getting done.
Sometimes these work requests had trivial, even strange things being requested. Someone wanted a report modified so that it was sorted a specific way [a rather bizarre request as I recall]. Turns out the accountant just needed information for all customers of type 'X' based on a field in the customer's database entry, and wanted them all together so she could type the numbers into a spreadsheet quicker instead of going through several hundred pages, blue-lining them, etc.. I offered to create a file she could import into the spreadsheet instead, with all of the values she needed already calculated. It was like "you can DO that"? [it was easier than her request in a lot of ways, and saved on the cost of the paper and toner to print 'yet another report' on].
Sometimes it just pays to just go and ask "why exactly do you need this" and work out a better solution. Fortunately, people were open to the concept, and usually happier with the results afterwards.
My motto was "Throw a problem over the wall and ignore any grumblings or other noises. I'll let you know when it is solved."
The managers who understood that were few and far between and they got exceptional results.
When it got to be that my job description was sit in my cube and answer questions and attend conference calls, I initiated my retirement. I was never going to be allowed to solve another puzzle, err problem. It wasn't worth the paycheck to sit in a cube.
I think describing things as a cargo cult nails it.
Management's primary goal should always be to ensure that they have the people to do a given job, keep them happy enough that they continue working, and assist them in getting the tools necessary to do their job. In some environments, that may result in using an agile model, in other environments some other description may apply. What matters is that the workers are able to work freely in a way that gets the best quality work done at a reasonable pace.
Putting a name to what your workers have wound up finding works best for them, then trying to apply that style forcibly upon a completely different group of workers is not going to work, and rarely does.
If you want to know what will best improve the output of your shop, ask the people doing the work, and help create that environment for them. People are different, and the mark of a good manager is enabling their workers to do what they're paid to do.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
