[08:00] First alarm goes off;
[10:00] I'm starting to wake up
[11:00] Some quick HN checking
[12:00] Ok, off to office.
[13:00] At the office; talking with customer if needed, otherwise desperately trying to get some work done amidst noise and distractions, including but not limited to people occasionally playing board games for a break.
[18:00] All my cow-orkers in the room have finally left for the day. Time to get some actual work done.
[21:00] Ok, time to head home.
[22:00] Let's eat something quickly and go to sleep.
[02:00] That side project is _way_ too interesting; I guess I'll be waking up at 10:00 tomorrow again...
So no help from me.
The other day, one of my cow-orkers asked me, how can I bear working late hours - it must be very lonely. I desperately tried not to answer that with "that's precisely the point".
Is your cow-orker also a software engineer (or "engineer" if you prefer, esp. in their case)?
I'm starting to think that a large majority of software developers actually like open-plan work environments with lots of interruptions, however they also don't browse forums like this very much. They do well (or well enough to keep their jobs) in these environments, enjoy them, but they don't hang out on places like this online either at work or after-hours, and go home to play with their kids or watch sports or hang out at bars.
This is a longer topic, but in my mind there's a bimodal distribution on a spectrum of attitude towards programming. Some, like me, are people in love with technology, who go home to tinker on side projects. Other - like that cow-orker - treat software as a career, and they go home to socialize, play board games with friends, etc. Without judging anyone, my impression is that our industry is mostly filled with the second kind of people now[1], and they seem to predominantly feel good in open-space offices.
In the end, I figured that my preferences must be in minority, so I don't complain too much. That is, unless someone is really distracting me for longer periods of time, at which point I'll kindly ask them to stop.
--
[0] - I'm not here to tell him how he should feel about his degree. For myself, looking back at the education I got, I think my feelings were best expressed by a friend of mine: "if for that I'm an engineer, then I'm afraid to go to a doctor".
[1] - I believe it used to be different in the past, but that impression might be colored by small exposure to the real software world in my teens; the kind of people you meet on-line in programming circles are usually self-selected to be tech lovers / geeks.
Don't worry too much: doctors get far more education and training than we engineers do, and it's a lot more rigorous. They have to get a 4-year undergrad premed degree, and then at least 4 years in med school, plus residency (which is basically on-the-job training), etc. It's nothing at all like engineering where you can get a BS in 4 years or so and then be set loose.
But I've seen way too many devs who seem to actually like being able to interrupt their coworkers to think that all devs hate that, and I've seen way too many comments on places like this in favor of open offices.
In my eyes it's really addicting, and I usually get this after-disco/cinema low when the amount of people in office starts to slow down.
What's the actual "engineering work" you are trying to do without interacting with people all the time?
Edit: I think most answers can be summarized as "When I'm left alone I get into the flow mode, and that's enjoyable". The same way I mostly get it when working together with a colleague on a problem. Both ways may not always be the most productive, but due to producing a good feeling we prefer these. I see, thanks for showing your points of view.
The biggest, most used solutions I helped building usually happened when I cooperated with others. The same discussions that happen in your head, just that part of it is coming from another brain.
This seems tricky to reconcile with the "everything is done by a team" model that's currently in vogue.
The above comic strip absolutely perfectly shows what's it about for me. Though I agree there is stuff better done with others (brainstorming, or discussing hard problems where you're stuck; also variants of rubber-duck debugging/designing; I'd say it boosts "breadth" and "lateral thinking"). But for many people there is most certainly also stuff better done alone ("depth" I suppose? often things like analysing interactions between subsystems; or building an algorithm; or reading docs or a paper; researching existing apps/solutions/libs in order to "spreadsheet" their pros & cons; also analysing/designing thread interactions; or debugging, building internal knowledge of a problem - which is also a required step before rubber-ducking, or generally discussing it, is even possible; also arguably maybe reviewing someone else's code).
Things I have to do fall into two categories - either I immediately know how to approach them, at which point I can code while having conversations and there's little you can do to distract me - or, I don't immediately know how to approach them, at which point I need time alone and in peace to load the whole system into my head and think through appropriate steps, possibly running mental simulations of several solutions in my head. The second kind of work is when I turn into a pretty antisocial person - I don't just avoid conversations, I avoid being in the same room with other people.
And frankly, second kind of work is kind of more important. It doesn't take skill to pump out hundreds of lines of code an hour. It takes skill and concentration to write those and only those lines that move the project forward in a way that's maintainable down the road.
With two people these complex systems often also end up in actual diagrams or code, which then can be tested or used for documentation and later lookup.
[1] http://stackoverflow.com/questions/43375012/wrapping-ones-he...
When the office slows down and things get quieter is when I find myself finally able to get completely focused in on things that require all of my attention.
I enjoy meetings, business talk, planning and miscellaneous conversations with coworkers more than (I think) most software developers, but to get any sizable software project done I do best with chunks of a few hours at a time to get into a focused state, get all of the moving parts loaded into my head, then actually write the code/fix the bug etc.
My solution to this–in an office that I share with people who talk on the phone–is to show up in the late morning after they've made their morning calls, and leave in the evening a few hours after they leave. This way we overlap in the afternoon, but I get some time with a quiet office where I can really think.
Just while writing this comment several conversations happened around me that drew my attention away from what I was writing. When I focused my attention back to the comment, I had to skim what I'd just written to 'reload' my thoughts. At least for me, this 'reloading' process takes a long time when it comes to writing software, despite various tricks I've come up with over the years to help speed it up.
--
[0] - Had long battles about that with my boss. He gave up after a year, realizing that there's no way to make me come before 10:00 regularly (my sleeping patterns are weird), but I am there when it matters and get the job done.
Isn't that the default in software departments/companies? However, usually that is considered an "asshole" by the general population, despite actually being a good reason for not reacting to nonverbal communication.
For example, I've become known as "the regex guy" at the office. I know regex really well as well as the ins and outs of the regex engines of languages we use. I don't mind when I get called over to help with a tough regex, or optimizing something. But way too often whatever I get interrupted and cross the building just to replace ".*" with ".+" or something equally simple.
I usually just type the solution and tell them my copy of Mastering Regular Expressions is on the office bookshelf if they'd like to borrow it, the first chapter should cover all the basics. I'm also very happy to explain the basics of regex to someone in my down time, but very few people have taken me up on that offer.
1. Give them a quick answer and point them to the book but they'll never read it and continue to interrupt even if you told them to not interrupt for trivial matters. On and now you're so much of patronizing dork. Back to square one.
2. Don't give them the answer, and point them to the book. Now you're the smartass jerk that doesn't socialize. Plus they won't read the book and invent some crazy solution to get shit done and later when you have to fix the mess the WTF/min ratio goes through the roof. Back to square one.
Which leaves you with three possible actions: DealWithIt, RageQuit, or RageFix, only one of them being a long term fix but things don't happen in a vacuum and you're not always in a position to do so.
Helping others is fun but I've been on both sides. There are plenty of people who always need help and never put effort in, and are extremely distracting and lower morale.
And interactions are not always of the "Hey can you explain this" variety. Sometimes it's your manager worrying about a project and nitpicking every detail and still managing to not know what's going on. Sometimes it's your manager trying to prove he is "technical" despite not being technical at all, and just downplays your work. Yes, I deal with this daily. Sometimes people are just assholes, and HR/management doesn't deal with it because they produce or are too afraid. Something else I deal with daily. And on top of that, sometimes I just don't want to talk to someone about something. I just want to focus and get done what I need to get done.
Building systems. Adding features to software. Debugging it. Anything more trivial than generating and wiring classes that someone else designed for you.
I guess a lot depends on the kind of work you're doing. In all of the projects I worked on, 90% of work time would be spend on actually doing it, and only 10% on talking about it (and most of that at the beginning, and then at some critical moments in the project). After the design discussions had been concluded and we've settled on appropriate division of labour (critical aspect: modularity, so that people can work in isolation and have to agree only on interfaces), it was mostly individual work.
Now don't get me wrong, I love helping others and answering their questions, or sitting with them and figuring stuff out. Just not all the time, and not in the very moment I'm trying to do something cognitively demanding (like redesigning half a dozen subsystems, or carefully weaving in new features requested by the client in a way that doesn't disrupt the rest of the application).
Would you prefer if a) the environment was quiet and no one was interrupting you. Or b) the environment was noisy and you were constantly interrupted by people talking about how they spent their weekend.
To many developers, productive work is like taking a math exam. Therefore we want the same kind of environment (a distraction free one) to do our best work.
I think it's hard to separate the questions of productivity and satisfaction. It's satisfying because you're being productive, but conversely it's easy to dodge the urge to procrastinate because the results are satisfying. So the two go hand in hand.
(And yes, I entirely recognise that for some people the satisfying+productive mode does involve intense, fine-grained collaboration, while for others it doesn't. I've seen both modes work, and don't really see why they shouldn't coexist -- although ideally with walls and doors to keep the noise of the collaborative types at bay!)
The interesting side effect is that people actually expect me to be listening sometimes when I'm not. So they will say something, expect a response, and not get it and it will surprise (and sometimes annoy) them. I've been unable to 'selectively' listen to avoid that, its either all on (and distracting) or all off (and not distracting).
Not unlike processing all of the works of Shakespeare into bags of words and n-gram vectors and correlation maps to get a handle on how you can slice and dice documents for search. Nobody expected the time spent slicing and dicing Shakespeare would generate useful work product, but it did help train you so that you could generate useful work product.
And like the Shakespeare exercises, once the benefit was realized you moved on.
lol, me too, I'm afraid to admit. Every dang day.
[05:00 - 06:00] Wake up with the sun, and work in bed on side projects on personal laptop;
[06:00] Get myself together, spend the only waking time I have with my infant child during the week.
[06:30] Gym
[07:00] Commute to work
[08:10] arrive at desk, have breakfast at desk while picking up on momentum from yesterday, or fixing what problem I was too mind-numbed to see through the afternoon before
[8:30 - 9:30] Everyone else streams in. Catch up on non-tech business developments in informal chat.
['til 6:30] Work, work, work + mental breaks on HN. Find 20 minutes for lunch. Tea somewhere around 4:00 - 5:30 PM. Occasionally impromptu meeting with my manager for rubber ducking, feature planning, or architecture question.
Can't complain. Tiny start-ups are great when the personalities fit.
Failing that rough time frame, it's off to a big firm or government where hours are tightly defined. As you're alluding to, time is too precious a resource to squander. I joined this last company not long ago and I'm very enthusiastic about it, but this is the last start-up I can see myself doing. Unless someone is independently wealthy, I don't see how the commitment it takes is an acceptable sacrifice for a full and satisfying life once kids come into the picture.
Serious question: How does this work? Do you work out for exactly 30 minutes and jump straight on transport / in the car / etc? 20 minutes plus a quick shower? Is there no time factored in for cleaning yourself up after working out, to be presentable at work?
Made the switch a year ago after moving from web developer to tech lead and having all the issues you mentioned. Now I'm just writing code again. Best decision ever.
These days I can work from home when I want, but I don't because it stresses me out not to have a clear separation between home and work.
It's really hard. Takes some practice and discipline. One good way is to literally switch everything off (computers phones) at the end of the day. Stops you from "just answering that email" etc.
Another good one is leaving the house (drop off kids, buy breakfast coffee, whatever) end then when you are back home you are "at work". Then repeat when leaving work.
I love being in the office until the cacophony of everyone else begins and the noise is maddening. Sometimes I don't want to need to listen to music to be uninterrupted.
I now work from home 2-3+ days per week, even though I live about 20 minutes from HQ.
tough I am reading the art of learning, and I have been trying to train myself to work in a distracting environment. Because you can never control your external factors.
you can write software any where you can take your cpu, pixel grid and network thing me bob
[06:15] First alarm goes off;
[06:45] Finally wake up, get out of bed, shower, shave, make espresso for me and the wife
[07:15] out the door, 30 minute commute to office
[07:45] breakfast bagel at my work cafe
[08:00] arrive at desk, begin contemplating work -- work on something I procrastinated on the previous day so that I can have a good standup report
[9:00] everyone arrives at office, noise increases 10x, I am physically unable to concentrate anymore. Earplugs and noise-deadening headphones help some, but then having those on distracts me
[10:00 til 05:45 or 6:30 pm] Constant battling distractions, meetings, interruptions, and general work-related chaos, trying to somehow manage to squeeze in any actual developer work. Work proclaims how 'fun it is to work here! awesome! totes cool! We have so much cool stuff! Our culture is the best culture!'
Help me.