Eh, no need to call in the Grammar Squad. Not to mention effect is correct here (effect means ‘to bring something about as a result’). Hacker News did bring something about as a result.
Grammar Squad here with the facts. And just the facts.
When effect is a verb, the object must be the change itself, similar to cause: "Hacker News effected a significant deterioration in site availability". With affect, the thing being changed is the object: "Hacker News affected the site."
Thanks for that input but HN is a casual site, not a uber professional one (i.e. place where most people look for jobs). I'm pretty sure we all know what it means.
Yes, everyone knows what it means. But if you make a claim like "effect is correct here" you are entering the debate, so don't call the debate off-topic when you lose.
Sadly I left that part out of the original claim. My apologies for perhaps sounding condescending.
Correction was imo:
a) correct (was proven false by you)
b) unnecessary - pedantry is only OK in strictly professional context, which I don't consider HN to be. This was omitted from original claim by my error (
http://www.youtube.com/watch?v=J7E-aoXLZGY).
I really meant to thank you for correcting me there i.e. "Thanks for that input". It might have came of as sarcastic, but was not my intention. There is nothing (of value) to win/lose in a debate. In fact losing debate is more enlightening.
Could you elaborate on that? Since that doesn't make too much sense to me. From what I know, the movement goes in the opposite direction: much of what was considered "grammar" in the past has been reinterpreted as a part of the lexicon, now that we actually have adequate technology to work with humongous corpora.
Sure. Linguists consider grammar to basically be what a person knows in order to say they are a fluent speaker of their language, which includes understanding words in that language. More narrowly speaking, lexical information is tied to syntactic information because certain syntactic constraints are imposed by our lexicons.
That's one of my favorite things about HN. People (typically) don't jump on top of the minor grammatical errors, typos, and misusages that pretty much everyone who doesn't triple-check their posts is inclined to make.
Unless they're particularly egregious, they're generally ignored and the content of the post is focused on instead.
IMHO, while working on challenging tasks (bugs mostly) where we are not able to figure out something, tiny breaks spent on unrelated subjects seem to help a lot. While interruptions are bad, a badly timed interruptions seem to be the worst.
It sometimes happens to me on my way home. I let my mind wander and briefly come back to a problem, often seeing it from an angle I haven't considered during the day.
In my experience tiny breaks away from the workstation are far more helpful than the ones that need you to use the computer. I have found taking a break from a programming session in form of checking HN, twitter makes the mind all more muddled.
Yes, let's grab a cigarette... or a coke, or a coffee. But all these circuit breakers are bad for health. The best I found out for now is to add hot water to my tea mug.
Well, links are always better with context or a title. Same with youtube links - I frequently don't click them when there is no context or any clue about the contents. And in youtube's case, it could be a rick roll.
A post that expresses little thought should be down-voted. The post in question is of value since the original link 503'd, but that value is obfuscated to some by the lack of a quick "Here's a mirror" explanation.
Back when I first tried opening the page it 503ed and there was just one page of comments, one of them was this image link. Its purpose was fairly clear, actually. And helpful.
No it's not clear but it was helpful. There is an implication that a simple imgur link could be a mirror of the comic image. But then you would have to know that the content of the article was a comic image.
The original page 503'd for me as well, and I wouldn't have known that the imgur link was a mirror if it wasn't for the replies to it (since I just Cmd+F "mirror" to find this).
Once upon a time I was working with a very challenging legacy code and I was building similar constructions in my mind. The office was sometimes noisy and chance of interruption was not that small. So I established a habit of writing kind of stack trace of my own thoughts so that I could easily come back to my state of mind after such thing. It looked like:
There is a bug in module X
Module is X is calling module Y when user is not yet activated
We are creating user subscription
We are using current subscription in subscription creation
Current subscription is A when user is not activated
Current subscription is B when user is activated
Probably bug in method c()
Think what is going to happen in situation M when changed the implementation to d().
The list sometimes had 12 elements that I was trying to fit in my head to find the solution to the problem. I now work remotely from home (quiet and all that) and most of the code that I work on is of much better quality (another company, better practices) but I still sometimes resort to this method when working on a complicated piece of code that is unfamiliar to me.
I have endless TextEdit files strewn around my hard disk with very similar contents, I need to hoover them up every now and again. It's really useful to type something out like this, even just to map the problem out in your mind.
I found it useful to start writing an email to some people concerned. I usually start with "it don't work", then because I don't want to look stupid I explain a bit what doesn't work, I feel the need to explain my thought about why do I don't look like unimaginative, and then I write down how I would check if I'm right, because I don't want to look like I'm not scientific, then I just try the test because I'm not supposed to be lazy, and then usually I trash the email because I found the bug.
This is one of the reasons I like to provide detailed commit messages, and encourage my team members to do the same. I treat the commit message like a short email to the team (even if that's only future me) about why and how I made the change. Summarizing the change in writing often uncovers logical flaws or missing edge cases. I've aborted my commit (after copying the notes for reference) more times than I'd like to admit when I've realized that I've not thoroughly tested something or missed updating that admin report that would be affected, etc. The act of 'telling someone' exercises different pathways in the brain and helps you think about the problem differently. As someone already pointed out - it's a flavour of rubber duck programming. It also works really well in a team environment where your CI system emails the whole team the commit notes. You get a low ceremony quick design review. "Did you update the X system/form/report when you changed Y?" replies happen more often than you think, and junior devs can actually learn a lot about an existing system just by seeing the approach used by other team members.
It's also a miniature version of literate programming. You can go through all the commits and get an explanation of how the program evolved -- not just the actual lines changed.
I never thought about it as something that can have such fancy name and such broad engineering application. I think my technique is like 1% of what Wikipedia describes.
The old "So you want to be a success at selling?" training video starring John Cleese has a wonderful example of (roughly) the Five Whys applied to sales.
I find it really helpful to write little notes and diagrams to help visualise the problem and as a basic mnemonic technique. There's not much space in your short term memory so it's better to offload some of the work if you can. I've started reading Your Brain at Work. It explains how your brain operates in laymans terms and offers some workarounds for common problems.
This is an interesting technique that I hadn't considered before. I can see that it would be useful when traversing unfamiliar code. Will try it out next time.
Programmers have been doing this from more than half a century. Its called debugging.
Its basically to learn to localize the problem to a specific part in the code/system. Study the inputs and outputs to that system. Establish single responsibility to that part of the code. Now study the input and expected output from that part of the code. If they mismatch, correct the code and test it out for all possible values of the input.
Additionally automate it/check list it such that those mistakes are not made in the future.
I was doing this in an open plan office using workflowy — surprisingly effective. It's almost as if you're doing a human equivalent of a context switch.
I do this same thing, but in a variety of circumstances. I find it not only helps me to keep my place, but the act of writing out or diagramming ideas helps me think and reason through problems better than if I just try to work them out in my head.
Yup! Same thing here.. the fact that I've got terrible ADD doesn't help - I keep such a "stack" open on stickies on the corner of my screen open so I can avoid drifting and stay on task.
It also provides a visual level of how deep you are into "shaving the yak" - once you're 10 levels into a problem, it becomes easy to forget what the original problem was.
I do similar to manage my stack — without it, more often than not, I find myself with a "blown stack." But these days, I'm actually using physical index cards. I've given up on todo apps — even ones that provide arbitrary nesting/trees (e.g. org-mode, Worfklowy, etc.).
I've considered using a simple stickies app, but there's something about pencil and paper that I find beneficial — or at the least, comforting — and I haven't quite put my finger on it. Not sure if it's the ability to do free-form sketching, or that I can quickly physically shuffle/order/arrange the cards, or that I can jot things down without needing to be at my computer/on a mobile device — or just being able to step/look away from a screen for a bit.
I'm thinking most likely it's that whatever added functionality or benefits I would get from using an app to manage this stuff would be offset by me fiddling around with features, settings, tweaks, etc., and screwing around "evaluating" different tools.
That's the same thing I've run into. It's a never ending cycle of trying an app (I love Omnifocus, it's just too much to deal with at times), reverting to something simpler (stickies app), yearning for some extra piece of functionality that doesn't exist (gee it would be nice if...), and then repeating the whole cycle over again.
I think meta-productivity is just too much damn fun to leave alone.
I'm the exact same way: I need a physical medium when it comes to notes, etc.
I discussed it with a another friend of mine (a business guy) who similarly prefers notes/notebooks and we seemed to hone in on the fact that its superiority over non-physical mediums comes from its freeform nature. The freeform nature allows you to record things in a format that more accurately models the way your mind works. This makes it easier to come back to and have your brain go "Aha yes I have a memory stored for this data because I created this note". With a physical medium, you're never (or at least, much less so) forced into any format that was created by another person (to-do apps, etc.).
Will show this to the wife. She has a hard time understanding why working on week-end projects by 45 minute chucks isn't effective as I need 20 minutes to get in the zone and restart my thoughts where I left them
There is one nice way to push oneself in the zone faster: just open a broken test in your test suite, it will point you to the next step. [edited to clarify]
I quite often leave my code broken so that next time I open the solution I know exactly where I left off. I will often leave a comment there or throw("get X to do Y now")
I do this as well -- once I have the complete solution to something in my head, I quickly go through the various parts of the codebase that will be affected and drop pseudo-code or even just rapid notes in each place -- which will intentionally break the compilation, so that I can use the compiler errors as a fast & direct way to pick up the threads again if I'm interrupted.
For non-compiled code I'll add a dozen line breaks and a note in all-caps to make it jump out in a diff.
Just leave for a couple hours. Between getting asked to open a jar, or get something off a shelf in the garage, or 'What do you think about...' every few minutes I could never get anything done at home with my SO around. And then you have the dog wanting to be fed, or walked, or who knows what else.
Just make sure she knows to not take it personal and she's not 'bugging' you, you just can't be interrupted. You'd think you'd get a ton done when you're completely alone, but that's not the case.
This is why I haven't been able to bring this up in my new environment (school). I know that people won't get it, and I just have a strong desire to avoid the admonishment :(
keep fighting the good fight :) eventually they'll learn, and the next programmer/creative/etc that has to deal with them will benefit. thank you in advance :)
I'm currently back in school in a non-programmer environment, and I honestly have a hard time bringing this sort of this up to most people I know here because I just know that they won't understand why this is so important and I just don't want to deal with the interpersonal mess :( :(
Apparently programmers are the only people who think about problems. You poor little unique flower.
Write it down. It will be clearer to you. You can more easily refer back to it. You will be interrupted. You will need to do other things before you finish your current grand opus. You will lose your place in your own thoughts just by trying to hold it all in your head the whole time.
You're right, though your post would be better without mocking people.
I don't have an habit of writing stuff down, but I know I really should. That said, a couple hours of interruption-free work doesn't seem an extravagant request.
Maybe just print this out and put it up next to your workspace. Never know who might read it and stop to think, without having any sort of confrontation.
anyone who spends any amount of time working near programmers, or gives a shit about their programmer coworkers should get this. If not, give them a copy of "Flow" and PG's essay on makers and managers and enlighten them.
Also, be aware that flow applies to all your non programmer friends too. I usually have to train people to respect the signal of the headphones. The most common compromise I've struck is that we IM each other first and ask "are you in flow?" before diving in. It's acceptable culturally to say "yes-ping me in 1 hour." etc.
But maybe that's because I've been in tech for over a decade now and so many people trained me right. :)
Well isn't that sort of like saying you should keep your documents on your harddrive instead of in RAM? Writing/drawing is fine but the actual processing can only take place in the head :-)
The main problem of pen+paper is it's only 2D. Modeling an entire process may require a lot more than 2 dimensions, so trying to put it in 2D is actually harder than modeling it freely in your head.
Exactly. And much slower as well. Obviously if you expect to be interrupted you can take the time to download your brain onto paper, but trying to do all your work on paper would be like running your CPU through a printer->scanner loop-back.
STUDYING:
You are all computer scientists.
You know what FINITE AUTOMATA can do.
You know what TURING MACHINES can do.
For example, Finite Automata can add but not multiply.
Turing Machines can compute any computable function.
Turing machines are incredibly more powerful than Finite Automata.
Yet the only difference between a FA and a TM is that
the TM, unlike the FA, has paper and pencil.
Think about it.
It tells you something about the power of writing.
Without writing, you are reduced to a finite automaton.
With writing you have the extraordinary power of a Turing machine.
Because editors are great recording tools but very bad thinking tools.
Nothing really beats the flexibility of pencil and paper. You can draw boxes, doodles, graphs, heuristics, flow charts, mind maps etc. Basically you can do what you can think and conceive of, with your mind as your only limit.
Needs a clock in the background to hammer home the point to non-programmers that it can take an hour to get from the 1st to the 6th panel. Bosses take note: an hours work has disappeared.
That's so accurate! The penultimate one should be putting on ear phones, then the last one showing someone coming over to your desk and interrupting :P
Very true. At the last place I worked I found I couldn't usually do any programming until after 5pm when others left, so I got a good couple of hours after that get programming done.
I disagree with what I think this picture implies. That is shielding the developer from interaction makes him/her more productive. In contrary, interruption and conversation belong to development. The more my fellow developer colleagues talk, the better the code base is.
My colleague (the one who talks the most) talks mainly about what has happened at his home, in his life, with his car, with his cat, with his child, ... I doubt there is an inherent code quality benefit in those topics.
Yes and no. Yes, talking can help bring a lot of people to a solution easier. Taking a coffee break and chatting with a co-worker about your current problem or pairing with another set of eyes is often vary helpful.
However, when you are really focused on a complicated problem it is hard to find a solution when your thought process is constantly interrupted.
There needs to be a distinct separation of Exploration mode and Implementation mode. This comic depicts a programmer in the latter mode where "collaboration" can be detrimental.
Exploration mode is crucial to the development workflow. It's a space where there isn't "right" or "wrong" and creatively constructive conversations can occur.
You're absolutely right that conversation belongs in development. But only at the right time for the highest effectiveness.
I don't mean to be a downer, and I certainly enjoyed this comic, but I fear that these are the kinds of posts that lead to communities becoming nothing more than memes and other quick laughs on reddit.
Well this was very specific programming related joke. If they stay like that and only pop up once in a while, it's fine.
Just enjoy the joke and stop worrying.
This is great! It articulates what most of us programmers feel internally when we're interrupted. What's I'd also love to see is a cartoon explaining the external effect of an interruption. Like, when you interrupt a programmer you're pulling the "stop" cord on an assembly line: it doesn't just effect that individual, but there is a net effect on the overall effort.
(FWIW, I don't think the assembly line is a good example, because programmers work in parallel, not in sequence, but it's the best sort-of-example I could think of on a Monday morning...)
I liken programmers to extremely expensive equipment for manufacturing software.
When a company invests in expensive equipment like that, it is very important to keep it producing output. So by sending programmers to meetings, your expensive equipment is sitting idle, offline, producing nothing.
Interruptions are like shutting down an entire assembly line. When you turn it in again, it will take time to be running smoothly again.
So to the managers and executives, it is your choice how to utilize this highly specialized, very expensive equipment. You can try to keep it running at full capacity, or frequently start it up and shut it down, take it offline, and leave it sitting idle.
Yes but no, because producing code is never smooth, or smooth code production is exactly the characteristic of these coding sessions you can interrupt without great loss.
I agree this is the weakest part of the analogy, as software production is so highly variable. You can have days where you see very little come out of the machine, then a great amount of valuable software come out, seemingly all at once.
I think, though, it does not invalidate the basic point of keeping the software producers on the task of software production as much as possible in order to maximize output.
One client I worked for had a "heads down Thursday", where no one was allowed to schedule anyone in the app dev department for meetings; general consensus was that Thursday's were by far the most productive day of the week
It's a trade-off. Stakeholders want to be able to discuss upcoming work and course corrections, but developers need uninterrupted time to get current work done.
When I worked as a team lead I created a rule that there could be no meetings in the afternoons. The daily schedule was that we'd have a morning scrum where everyone would say what they did yesterday and plan on doing today. That was also an opportunity to schedule any meetings for the day, to be done immediately following the scrum. As team lead I considered it my job to take on that burden, when possible, and fill in the rest of the team with the pertinent details afterwards.
It worked out fairly well: stakeholders could schedule time any day to talk to the dev team, but every afternoon (at least) was no-outside-interruptions development time.
In this case it was a distributed team with most the members in Romania (GMT+2) and Armenia (GMT+4) with myself in Ottawa, Canada (GMT-4/5). So our normal working day only overlapped for an hour or two in the morning. So, we didn't have a choice that way when to hold meetings.
At some points in the project my day often ended up being half meetings, half development. Lunch ended up being a break where I'd switch modes from 'team lead' to 'developer'. It wasn't ideal for me, but it was ideal for the rest of the team and I considered that my top priority.
Many programmers (at least me) have varying levels of peak output in a day.
Some times I literally can't make my brain work after 2 - 3 hours of in-the-zone work. I just can't read lines off a screen anymore.
Other times I can go 24+ hours without breaking a sweat.
I think in practice your average programmer can't operate on the 40 hour a week traditional work schedule and actually output solid performance for all 40. On average, at least. So maybe the first businesses to start introducing meetings and such were attempting to pace their SE staff and actually saw positive results, since they still got whatever the maximum output one engineer could put out before their brain went to mush in a week but also had them talking to clients or discussing other things.
It is just the industry latched on to bureaucracy without postulating why it might be useful. You want your SE coding whenever possible.
That's pretty much the same as me. But I do know people who can do the 7 hour full force ahead. And interrupting those people generally results in very little getting done.
For the rest of us there is always code reviews and emails and other fun things that needs to be handled and requires less brain power (well code reviews should require more but let's ignore that).
+1 here. There is also a pressure to get things done when I don't feel like getting things done - as in I don't have the inspirations to write that piece of code / that code is so ugly and hard to write.
Then a day or two later I would come up with a better solution and boom, milestone achieved.
But without forcing yourself to write that code, the breakthrough wouldn't come in a day or two. The breakthrough will never come.
Writing that crappy code that feels like pulling barbed wire through your brain forces you to think about the problem. To look at the corner cases, to really figure out a solution.
The breakthrough in a few days is just a cleaner solution you were able to come to after a deep understanding of the problem.
Not sure why someone downvoted you. While it's true that not all work is pleasant and sometimes we have to force ourselves to get things done, I think it's equally true that for solving difficult problems reflection is necessary. Especially as I get older and more experienced, I feel like my brain has more fodder for solutions but it takes more time to tumble around and fall into place. A lot of things besides actually sitting down and coding can help: getting 8-9 hours of sleep, talking over the problem with someone (even non-technical), getting some exercise, mind-mapping / wireframing, staring into space for hours at a time, etc.
I completely agree. I'll have a day at work where I just do not want to code, and anything I create will be garbage. Sometimes I'll do a rough prototype of what actually needs to be done, which will get my brain thinking. A day or two later, everything clicks into place in my brain and I go through, rework the prototype, and create a great piece of code I'm happy to turn in. If I get interrupted during that period of programming though, I usually lose my train of thought which make me stumble to catch up again. The prototype helps because I can see what I was doing if I was interrupted
This is the reason why my productivity has gone down since going from single to having a family. When I was single, I would just cut out early on the days I wasn't in the zone, and get some errands or housework done.
When I was in the zone, I would stay at work until right before I would go to bed.
This way I would spend nearly all of my "in the zone" time doing work.
Now that I have kids and such, I leave at 6 every day regardless of my productivity level, so even though I spend only slightly less time at work, my net productivity is way lower.
In the same situation I think my productivity is actually equivalent with fewer hours after having kids because it has created an ongoing sense of urgency to get done what I can in the 8:30-5:30 window. In the old days, 4pm was almost like the half-day mark, which personally led to a mental slackness about how much time I had left to accomplish a given task that day.
These days, I sometimes get cut out of the zone by quitting time, but more often than not I am mentally exhausted and ready to go. I'm sure that this would not apply to the most focused and driven programmers, but I'm also sure that a lot of young startup types are fooling themselves that the long hours they put in are giving them better returns than they would get with a bit more sleep, a bit more exercise and a bit more downtime.
Anyone can take a great photograph. The professional photographer learns techniques to take great photos more frequently.
In a sense, "professionalism" in any field implies a certain "frequency of success". For a programmer, that means learning techniques to accomplish tasks even when you aren't "in the zone". This means learning to get in the zone, how to stay in the zone, and learning to produce when you're nowhere near the zone. This requirement is universal to all professionals, including all professional programmers[1]
I would add that learning to approach your work even when you don't feel like it can sometimes yield surprising insights. Your brain is recoiling from work, but only as it approaches it from certain directions. It is possible to approach a problem from other angles, and getting "in the zone" from another angle can sometimes yield unexpected improvements to the product for the simple reason that you're looking at it in a new way.
[1] There are two categories of professional programmers, the hired guns and the artists. They both want to build great things. The hired-gun wants to build things faster and to spec. To him, "great things" is unambiguously defined as 'the things that will satisfy the customer'. All businesses love a speedy, accurate programmer - especially if they can be speedy and accurate in a non-disruptive way. Such programmers are very good at understanding existing codebases, processes, and doing the minimum work to get the job done. Often they simply do not care about technical debt - (indeed, they are incentivized the other way, to maintain (and even increase) technical debt, every bit of which only improves their negotiating position with the client.)
Meanwhile the artist-programmer success is not defined by conformance to a spec. Success is harder to define - but the artist can define success as getting the time to perfect his creations, traveling ever higher up that diminishing returns curve, going higher than most people are willing to go. This kind of programmer is the dreamer, the architect, the creative. This can be a backend architect, or a front-end perfectionist. They share the common goal of mastery and beauty. Most, if not all, programmer heroes come from this category. And rightly so, I think.
Nicely put. Yes, programming is part art and we are not like machines that can work no matter in what state we are. But often we mask our procrastination/laziness blaming it on lot many things and waiting for a right moment to magically arrive get the work done.
I am reading 'Dune' now and I found this advice from Halleck to Paul so relevant :
'I guess I'm not in the mood for it today' Paul said.
'Mood ? Halleck's voice betrayed his outrage even through the shield's filtering.
'What has mood to do with it? You fight when the need
arises - no matter the mood! Mood's a thing for cattle or
making love or playing the baliset. It's not for fighting'
While this applies to many things people do, i don't think it applies to programming. Programming is a continuous activity of concentration done over the course of 8 hours, 5 days a week, roughly 45 weeks a year. Meanwhile fighting of many kinds is something that happens in short bursts of extreme focus and excertion.
In fact, programmers have to "fight" too, and it is highly different from their daily work: It is when the software is burning cash and they have to find the problem and implement a fix right now. Most programmers find that they deal with that extremely well, though it usually happens at the cost of the rest of the day.
I find that meetings kill productive time later, especially ones that are pure bureaucracy/managerial dickwaving.
It's certainly the case that I can't grind out code 40 hours per week, but I don't think that sticking meetings in the "unproductive" time helps matters at all.
My current company has engineers pair-programming full time. On first reaction, engineers and managers tend to think that results in 50% net productivity. My experience has shown that people tend to average each other out. There are days where I'm well aware of how poorly I'd program, but I can still navigate my pair out of the pit of despair.
It also tends to cut down on meeting times because two sets of eyes are usually looking at any given piece of code, so knowledge disperses among the team organically so long as we swap pairs regularly.
I think this is a good point. In addition to not "shutting down the assembly line" it's important to set the proper direction. Many interruptions come from poor planning. "Stop doing that, do this," frequently is the result of not thinking through things to begin with.
Though I like your analogy, most programmers I know would rather say, "Don't interrupt Picasso" rather than "Don't stop the Lexus factory" :-)
"usually" Is a bit harsh IMO. It can be a lot of times, but then that's a symptom of a much bigger problem. It's hint, more often than not, that the environment is toxic and it may be time to dust off your CV.
That's a sign that you're in a fairly unhealthy workplace culture. Get out!
Meetings can be useful tools if you make sure to involve the right people and stay focused. This doesn't require anything special. Just define what you want to decide in the meeting, prepare for it ahead of time, and come to the required decision in the meeting -- discussing as necessary.
If you do that, it was a useful meeting. I have one or two such meetings a week at work, occasionally even three. They're rarely scheduled by management, but instead by the engineers building the system.
Meetings can also be used to disseminate information.
Sadly true. I like a turn of phrase from Peopleware - "Status meetings are generally ways for the manager to assert their status as manager." I've had many an inexperienced manager sit there and rotate through talking to each minion in turn, while the other N-1 minions sat silently thinking about what they were going to have for lunch today. Even better are the "stand-up" meetings that have everybody sitting around for an hour every morning, totally killing any motivation or energy for the day.
Thankfully I've escaped that sort of nonsense, but it seems like it can pop up anywhere.
While I agree - the issue is when nearly everyone in a dept is 'expensive equipment' - do you send the most junior person? The most experienced? Get someone non-technical to go to meetings and collect requirements? But what happens when they are asked to estimate (on the spot) and discuss the possibility of new features?
While I totally agree with not disrupting working people - I don't think you should ring fence them out of input in the process of defining product - we've all seen what happens in that case - "requirements" nailed down by a non technical team. And it's even more wasteful to have people working on the wrong things, or worst still being given so overly defined work that there is no room for them to add any value or find a better and faster solution.
While good management can help shield teams from unwanted intrusion - everyone needs to get involved in the process of manufacturing great software - which doesn't just mean attending meetings, but taking time to actively plan and consider the issue before the session. If your company values your input enough to bare the cost of asking you to be involved, then you should look upon that as a positive thing (unless they REALLY are just wasting your time with 'busy' meetings, which are really just wasting everyone's time - and it's a sign of either having money to burn with limited direction or a company going the wrong way fast)
Well let's see if I can stretch my metaphor to address your points. :)
Equipment needs to be maintained to continue working at peak efficiency. Sometimes it needs to be taken offline for repairs or routine maintenance. Or maybe you realize you need to switch over an assembly line to build a different product or model more important to your bottom line.
So, yes, there are times when the software manufacturing equipment will not be manufacturing software. But you want to keep that time to a minimum and understand the cost to the business of having the equipment offline.
Don't get me wrong, I totally agree with your point, but I meet a fair few devs who don't want to get involved in meetings - then complain about lack of information or clarity later in the project.
But other distractions as shown in the comic, I totally agree with doing everything teams, companies and individuals can do to remove all those distractions and keep people working however best works for them.
My favorite is when I try to take my laptop to a meeting so I can, you know, actually get some work done. And then, I'm lucky to get 5 minutes of useful work done for each hour of meeting.
210 comments
[ 5.9 ms ] story [ 248 ms ] threadWhen effect is a verb, the object must be the change itself, similar to cause: "Hacker News effected a significant deterioration in site availability". With affect, the thing being changed is the object: "Hacker News affected the site."
Correction was imo: a) correct (was proven false by you) b) unnecessary - pedantry is only OK in strictly professional context, which I don't consider HN to be. This was omitted from original claim by my error ( http://www.youtube.com/watch?v=J7E-aoXLZGY).
I really meant to thank you for correcting me there i.e. "Thanks for that input". It might have came of as sarcastic, but was not my intention. There is nothing (of value) to win/lose in a debate. In fact losing debate is more enlightening.
Obviously, as this is in the purview of the Lexicology Squad, not the Grammar Squad.
"Hacker News did bring something about as a result."
Except that Hacker News did not bring about the existence of the linked site, which would be the actual meaning of "effected the site".
Unless they're particularly egregious, they're generally ignored and the content of the post is focused on instead.
Turn off your e-mail client, phone, messages, internet connection, HN.
Link: http://www.youtube.com/watch?v=f84n5oFoZBc
Is this really a big deal?
Don't Wake Up the Programmer!
http://alexthunder.livejournal.com/309815.html
I use NV on MacOS, the SimpleNote app on iPhone and iPad, and the SimpleNote website on Windows.
(It can be seen at http://www.videoarts.com/sales-and-negotiation/so-you-want-t... at 15:15 , but alas only after registration now.)
What OP mentions is taking notes of his though process as he goes along, so he can jump back in after an interruption.
Its basically to learn to localize the problem to a specific part in the code/system. Study the inputs and outputs to that system. Establish single responsibility to that part of the code. Now study the input and expected output from that part of the code. If they mismatch, correct the code and test it out for all possible values of the input.
Additionally automate it/check list it such that those mistakes are not made in the future.
It also provides a visual level of how deep you are into "shaving the yak" - once you're 10 levels into a problem, it becomes easy to forget what the original problem was.
http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gs...
I've considered using a simple stickies app, but there's something about pencil and paper that I find beneficial — or at the least, comforting — and I haven't quite put my finger on it. Not sure if it's the ability to do free-form sketching, or that I can quickly physically shuffle/order/arrange the cards, or that I can jot things down without needing to be at my computer/on a mobile device — or just being able to step/look away from a screen for a bit.
I'm thinking most likely it's that whatever added functionality or benefits I would get from using an app to manage this stuff would be offset by me fiddling around with features, settings, tweaks, etc., and screwing around "evaluating" different tools.
I think meta-productivity is just too much damn fun to leave alone.
I discussed it with a another friend of mine (a business guy) who similarly prefers notes/notebooks and we seemed to hone in on the fact that its superiority over non-physical mediums comes from its freeform nature. The freeform nature allows you to record things in a format that more accurately models the way your mind works. This makes it easier to come back to and have your brain go "Aha yes I have a memory stored for this data because I created this note". With a physical medium, you're never (or at least, much less so) forced into any format that was created by another person (to-do apps, etc.).
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
For non-compiled code I'll add a dozen line breaks and a note in all-caps to make it jump out in a diff.
Just make sure she knows to not take it personal and she's not 'bugging' you, you just can't be interrupted. You'd think you'd get a ton done when you're completely alone, but that's not the case.
Need to find places where we can post it to NON-programmers
Write it down. It will be clearer to you. You can more easily refer back to it. You will be interrupted. You will need to do other things before you finish your current grand opus. You will lose your place in your own thoughts just by trying to hold it all in your head the whole time.
I don't have an habit of writing stuff down, but I know I really should. That said, a couple hours of interruption-free work doesn't seem an extravagant request.
Also, be aware that flow applies to all your non programmer friends too. I usually have to train people to respect the signal of the headphones. The most common compromise I've struck is that we IM each other first and ask "are you in flow?" before diving in. It's acceptable culturally to say "yes-ping me in 1 hour." etc.
But maybe that's because I've been in tech for over a decade now and so many people trained me right. :)
It's not that we can't figure out HOW to show it to non-programmers, it's that we DON'T.
I have 50+ retweets of it in my feed - all programmers sharing with other programmers. Don't do that. Go post it somewhere where OTHERS will see it.
STUDYING: You are all computer scientists. You know what FINITE AUTOMATA can do. You know what TURING MACHINES can do. For example, Finite Automata can add but not multiply. Turing Machines can compute any computable function. Turing machines are incredibly more powerful than Finite Automata. Yet the only difference between a FA and a TM is that the TM, unlike the FA, has paper and pencil. Think about it. It tells you something about the power of writing. Without writing, you are reduced to a finite automaton. With writing you have the extraordinary power of a Turing machine.
http://www.cs.cmu.edu/~mblum/research/pdf/grad.html
Nothing really beats the flexibility of pencil and paper. You can draw boxes, doodles, graphs, heuristics, flow charts, mind maps etc. Basically you can do what you can think and conceive of, with your mind as your only limit.
http://rix0rrr.tumblr.com/image/42866777562
You can't win with some people...
Employers: take note.
However, when you are really focused on a complicated problem it is hard to find a solution when your thought process is constantly interrupted.
Exploration mode is crucial to the development workflow. It's a space where there isn't "right" or "wrong" and creatively constructive conversations can occur.
You're absolutely right that conversation belongs in development. But only at the right time for the highest effectiveness.
(FWIW, I don't think the assembly line is a good example, because programmers work in parallel, not in sequence, but it's the best sort-of-example I could think of on a Monday morning...)
When a company invests in expensive equipment like that, it is very important to keep it producing output. So by sending programmers to meetings, your expensive equipment is sitting idle, offline, producing nothing.
Interruptions are like shutting down an entire assembly line. When you turn it in again, it will take time to be running smoothly again.
So to the managers and executives, it is your choice how to utilize this highly specialized, very expensive equipment. You can try to keep it running at full capacity, or frequently start it up and shut it down, take it offline, and leave it sitting idle.
I think, though, it does not invalidate the basic point of keeping the software producers on the task of software production as much as possible in order to maximize output.
When I worked as a team lead I created a rule that there could be no meetings in the afternoons. The daily schedule was that we'd have a morning scrum where everyone would say what they did yesterday and plan on doing today. That was also an opportunity to schedule any meetings for the day, to be done immediately following the scrum. As team lead I considered it my job to take on that burden, when possible, and fill in the rest of the team with the pertinent details afterwards.
It worked out fairly well: stakeholders could schedule time any day to talk to the dev team, but every afternoon (at least) was no-outside-interruptions development time.
I usually get the most done in the morning. I would not be as productive if I had nothing but meetings until lunch.
(It doesn't sound like "nothing but meetings until lunch" characterizes your team, I'm just making a point)
At some points in the project my day often ended up being half meetings, half development. Lunch ended up being a break where I'd switch modes from 'team lead' to 'developer'. It wasn't ideal for me, but it was ideal for the rest of the team and I considered that my top priority.
Some times I literally can't make my brain work after 2 - 3 hours of in-the-zone work. I just can't read lines off a screen anymore.
Other times I can go 24+ hours without breaking a sweat.
I think in practice your average programmer can't operate on the 40 hour a week traditional work schedule and actually output solid performance for all 40. On average, at least. So maybe the first businesses to start introducing meetings and such were attempting to pace their SE staff and actually saw positive results, since they still got whatever the maximum output one engineer could put out before their brain went to mush in a week but also had them talking to clients or discussing other things.
It is just the industry latched on to bureaucracy without postulating why it might be useful. You want your SE coding whenever possible.
For the rest of us there is always code reviews and emails and other fun things that needs to be handled and requires less brain power (well code reviews should require more but let's ignore that).
Then a day or two later I would come up with a better solution and boom, milestone achieved.
Writing that crappy code that feels like pulling barbed wire through your brain forces you to think about the problem. To look at the corner cases, to really figure out a solution.
The breakthrough in a few days is just a cleaner solution you were able to come to after a deep understanding of the problem.
When I was in the zone, I would stay at work until right before I would go to bed.
This way I would spend nearly all of my "in the zone" time doing work.
Now that I have kids and such, I leave at 6 every day regardless of my productivity level, so even though I spend only slightly less time at work, my net productivity is way lower.
These days, I sometimes get cut out of the zone by quitting time, but more often than not I am mentally exhausted and ready to go. I'm sure that this would not apply to the most focused and driven programmers, but I'm also sure that a lot of young startup types are fooling themselves that the long hours they put in are giving them better returns than they would get with a bit more sleep, a bit more exercise and a bit more downtime.
In a sense, "professionalism" in any field implies a certain "frequency of success". For a programmer, that means learning techniques to accomplish tasks even when you aren't "in the zone". This means learning to get in the zone, how to stay in the zone, and learning to produce when you're nowhere near the zone. This requirement is universal to all professionals, including all professional programmers[1]
I would add that learning to approach your work even when you don't feel like it can sometimes yield surprising insights. Your brain is recoiling from work, but only as it approaches it from certain directions. It is possible to approach a problem from other angles, and getting "in the zone" from another angle can sometimes yield unexpected improvements to the product for the simple reason that you're looking at it in a new way.
[1] There are two categories of professional programmers, the hired guns and the artists. They both want to build great things. The hired-gun wants to build things faster and to spec. To him, "great things" is unambiguously defined as 'the things that will satisfy the customer'. All businesses love a speedy, accurate programmer - especially if they can be speedy and accurate in a non-disruptive way. Such programmers are very good at understanding existing codebases, processes, and doing the minimum work to get the job done. Often they simply do not care about technical debt - (indeed, they are incentivized the other way, to maintain (and even increase) technical debt, every bit of which only improves their negotiating position with the client.)
Meanwhile the artist-programmer success is not defined by conformance to a spec. Success is harder to define - but the artist can define success as getting the time to perfect his creations, traveling ever higher up that diminishing returns curve, going higher than most people are willing to go. This kind of programmer is the dreamer, the architect, the creative. This can be a backend architect, or a front-end perfectionist. They share the common goal of mastery and beauty. Most, if not all, programmer heroes come from this category. And rightly so, I think.
I am reading 'Dune' now and I found this advice from Halleck to Paul so relevant :
'I guess I'm not in the mood for it today' Paul said.
'Mood ? Halleck's voice betrayed his outrage even through the shield's filtering.
'What has mood to do with it? You fight when the need arises - no matter the mood! Mood's a thing for cattle or making love or playing the baliset. It's not for fighting'
-- Dune, Frank Herbert
In fact, programmers have to "fight" too, and it is highly different from their daily work: It is when the software is burning cash and they have to find the problem and implement a fix right now. Most programmers find that they deal with that extremely well, though it usually happens at the cost of the rest of the day.
It's certainly the case that I can't grind out code 40 hours per week, but I don't think that sticking meetings in the "unproductive" time helps matters at all.
It also tends to cut down on meeting times because two sets of eyes are usually looking at any given piece of code, so knowledge disperses among the team organically so long as we swap pairs regularly.
Though I like your analogy, most programmers I know would rather say, "Don't interrupt Picasso" rather than "Don't stop the Lexus factory" :-)
Meetings scheduled by managers stand out from the crowd, but if you count them up, are actually a minority (at least for me).
Meetings can be useful tools if you make sure to involve the right people and stay focused. This doesn't require anything special. Just define what you want to decide in the meeting, prepare for it ahead of time, and come to the required decision in the meeting -- discussing as necessary.
If you do that, it was a useful meeting. I have one or two such meetings a week at work, occasionally even three. They're rarely scheduled by management, but instead by the engineers building the system.
Meetings can also be used to disseminate information.
Thankfully I've escaped that sort of nonsense, but it seems like it can pop up anywhere.
While I totally agree with not disrupting working people - I don't think you should ring fence them out of input in the process of defining product - we've all seen what happens in that case - "requirements" nailed down by a non technical team. And it's even more wasteful to have people working on the wrong things, or worst still being given so overly defined work that there is no room for them to add any value or find a better and faster solution.
While good management can help shield teams from unwanted intrusion - everyone needs to get involved in the process of manufacturing great software - which doesn't just mean attending meetings, but taking time to actively plan and consider the issue before the session. If your company values your input enough to bare the cost of asking you to be involved, then you should look upon that as a positive thing (unless they REALLY are just wasting your time with 'busy' meetings, which are really just wasting everyone's time - and it's a sign of either having money to burn with limited direction or a company going the wrong way fast)
Equipment needs to be maintained to continue working at peak efficiency. Sometimes it needs to be taken offline for repairs or routine maintenance. Or maybe you realize you need to switch over an assembly line to build a different product or model more important to your bottom line.
So, yes, there are times when the software manufacturing equipment will not be manufacturing software. But you want to keep that time to a minimum and understand the cost to the business of having the equipment offline.
But other distractions as shown in the comic, I totally agree with doing everything teams, companies and individuals can do to remove all those distractions and keep people working however best works for them.
Send a manager to the meetings, and get that manager to do a nice write up, with action points, afterwards. Email that round the team.
The people with people skills do the people stuff, and the people with coding skills don't "waste" a couple of hours in a frustrating meeting.
Edit: I meant plaintive, but my eyes were still crusty with sleep, and I am a giant dummy.