Slashdot Mirror
How Many Hours a Week Can You Program?
An anonymous reader writes "How many hours a week should a full-time programmer program? Trying to program anywhere near 40 wears me out. On a good week, I can do 20. Often, it is around 10 or 15. I'm talking about your programming session at the console, typing — including, of course, stopping and thinking for a minute, but not meetings, reading programming books, notes, specifications, etc., which by comparison feel like lunch breaks. I rarely get called to meetings (which is good) but that means to keep my brain from overheating I spend several hours a week surfing the web (usually reading tech news but also a few stops on Facebook, email, etc.). I should add that I am interrupted a few times per day. Me and another guy maintain an intranet site of a couple dozen web apps for an IT department, so we work on a few different things: phone calls, bug fixes, feature adds, as well as writing new web apps from the ground up, all in a day's work. And I know that wears a person out more than if they had just one project to work on. I wonder if programming is like mental sprinting, not walking, so you can only do it in bursts. Am I normal or stealing?"
If you mean purely the process of typing in code, well--that's kind of hard to gauge, isn't it? I've always found that the trial-and-error of development processes means that unless you're working in an orthodox manner it's really hard to separate "thinking" from "doing". Also, I find that when you're in the "zone" it's not painful at all. Sounds like you may be working on something you don't enjoy so much? :D
As long as you're interested in what you program, you can easily do it full work days. However it seems like you're doing the usual code monkey job - these effects are what happens when its not fulfilling or at all interesting. Not in your area of interest and not challenging in the needing-to-think-and-solve-problems way, but just to produce code. That's what it basically comes down to.
A friend of mine gets his job done and still plays computer games and codes his own projects at work a lot. Since he gets his work done, it's not a problem (though he hasn't told this). Another programmer I know spends 30-40 minutes breaks playing Civilization or other games he enjoys and his boss knows this and likes it because after those gaming breaks he has unwind, maybe has think some of the problems and gets really good programming done again. But he works at a software house, attends to meetings and is in other ways involved in the business too.
It's no surprise that so many programmers also go as developers later. You get to solve actual problems and do more interesting stuff. When you were a teen, you didn't just program - you developed and spend time thinking what you did. It's no fun if you leave that part out.
That's easy! I can do 169, no problem. Of course, I'll be tired and I may make a mistake here and there.
I rarely get called to meetings (which is good) but that means to keep my brain from overheating I spend several hours a week surfing the web (usually reading tech news but also a few stops on Facebook, email, etc).
My only work product is Excel spreadsheets and the occasional Word document. When I'm building these spreadsheets and documents, I'll get data for them over the phone, which I promptly type into my computer. The net impact is that I'm sitting at my computer all day, 40 hours a week. You just can't sit there and work spreadsheets all day, every day. If your job doesn't involve anything else, you're probably going to end up browsing the web to stay sane.
168 hours per week. 191 if you're onboard Air Code One and circling the globe in DEFCON style.
Eight hours a day, five days a week was good enough for illiterate industrial workers doing manual labor when it was invented 150 years ago. I see no reason it shouldn't be a perfect fit for highly educated software engineers in 2010!!
Look, you aren't stealing. You aren't stealing until you're fired and you keep coming to work and forcibly removing money from your employer without their consent. That doesn't happen very often. Whoever says you're stealing by investing your time as you see fit is full of bullshit. You control your productivity and if your employer don't like it, they'll get someone else. It's that simple.
Now that said, I have no problem doing forty hours of sheer coding in a week. Meetings take up a lot of time but in one of my former positions as a lead developer, I did serious coding to make us look really really good. It involved 50-60 hours a week of being there and 30-40 was actually coding to make sprint deadlines. I mean code overnight into the next day with no sleep. And no interruptions! My god, you would not believe the lines of code (note: bad metric) I can put away with no interruptions. That's what headphones are for. Amen to the large DJ sized headphones I have at work. It's a polite do-not-disturb sign to my coworkers.
Coding involves also searching online so you don't re-invent the wheel. Aside from that, your list is good. And yeah, meetings are important for coding. How else do I get my requirements other than directly meeting the customer? That's part of coding unless you're leaving that up to some other guy to get (which is a horrible idea in my opinion).
Anyway, sounds like you're getting the job done and you're not pulling your hair out like I once was. So what's the problem? You may not realize it but you may produce forty hours of normal developer work in those ten hours. I don't know, maybe your code is less buggy than mine? Either way if the paychecks keep rolling in and your employer isn't hold an axe over your head, what's the problem?
My work here is dung.
To this day I sometimes catch myself working on some interesting problem at home and putting in 30+ hours over three days when I've got some time off from work, because the problem is interesting and there's no one around to make it uninteresting by coming up with changes halfway through, demanding arbitrary things that have no place in the app and similar stupidity.
But when I'm at work building some glorified CRUDified spreadsheet in WEB_LANGUAGE_OF_CHOICE and I can't get two hours of coding in before the specs change or some PHB from another department feels like pointing out that the blue background color is a bit too blue for his tastes or whatever, well I sometimes end up taking a lot of little breaks just to clear my head enough to be able to function at all.
Greylisting is to SMTP as NAT is to IPv4
If quiet, uninterrupted and sleeping peacefully (coding something interesting/challenging) I could go easily for 8 hours or more. However if you interrupt me, and this could be a meeting, lunch or even a visit form a coworker it can knock me out of my coding (wake me up) and it's usually going to take me some period of time to get back into the flow of it all. The longer the interruption usually the longer it takes for me to get back into it. Caffeine and other Nootropics can contribute to to length and motivation to get back to work.
When I was 20, I would program 8-10 hours a day, then go home and code for 4-6 hours into the night.
Now I get distracted before an hour's coding is up. That's why I moved into management.
The cake is a pie
/p>yessir, i have no problem wiht a 40 hour weel of html coding and i >i>never,/i. maek a mistake.,
This ain't rocket surgery.
I think it changes with age. When I was quite young, 10 hour a day for days on end wasn't so hard to pull off. Remembering to sleep and shower and brush my teeth were harder. The catch was that a very high percentage of the code I'd write was either pure crap, or could have been done better in less time by writing another program to write that code. As I've gotten older, I've found that it's easier to spend a large number of hours *contemplating* code -- but hard to work other than in smaller bursts actually writing the code. The difference is that when I do write code, the hours are far less wasted.
I've taken this into account and so now my plan is, that when I reach 90, I'll just wake up in the morning and fart. My heavily customized Emacs will analyze the fart and translate it into C. "Oh, boy, I wrote another new OS kernel this morning!"
Well, ok, one of the two above paragraphs is true and not the other.
In the right environment on the right projects with the right team....I could easily design, develop, and test for 40+ hours a week and feel energized. Unfortunately that right environment, project and team is very rare.
I think bigger question is how many hours a week are you actually able to program when you consider all interruptions. I rarely am able to program for more hours than my brain is capable of.
When you have managers wanting meetings three times a week (granted, they are short usually), you expect to get a least a few inquiries a day about the code from someone who's not understanding what you are doing, and you work from home and/or you just get called frequently by the Significant Other... all these interruptions break up your day resulting actual concentrated programming being hard to do for any length of time.
I find I probably only spend 10 - 16 hours a week doing solid coding. Another 10 - 16 is spent just thinking about higher level things like architecture or scaling issues or whatever, and depending on the week 4 - 8 hours "alternately stimulating" my brain with related (slashdot) but not directly applicable stuff. The rest is taken up by the aforementioned interruptions.
But I'm not a "grunt programmer" either.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
So what if I am ? I have no problem coding circles around people that , oh wait a minute there goes a bunny.
Thinking is a physical thing, it requires energy, and can tire you out. If your body isn't in good health, you're not going to be able to concentrate for long periods of time without getting exhausted. If you aren't feeding yourself properly, you aren't going to have enough nutrients to keep your brain going.
Now, being in good physical form doesn't mean being skinny: you can have terrible energy levels even if you are skinny, and you can have amazing levels even if you are fat. That said, the easiest way I've found to increase energy levels are first, to get enough nutrients (proteins, carbohydrates, fats, vitamins, fruits and vegetables) so your body can rebuild itself, and second, running. If you can run far, you will be able to program 60 hours a week without a problem. If you want inspiration (ie, extra motivation beyond just high energy levels), check out this book (I've no relation to the author, just found it inspiring).
Whether you would want to program 60 hours a week is a different question.
Qxe4
Peter Gibbons: Well, I generally come in at least fifteen minutes late, ah, I use the side door - that way Lumbergh can't see me, heh heh - and, uh, after that I just sorta space out for about an hour.
Bob Porter: Da-uh? Space out?
Peter Gibbons: Yeah, I just stare at my desk; but it looks like I'm working. I do that for probably another hour after lunch, too. I'd say in a given week I probably only do about fifteen minutes of real, actual, work.
Knowledge = Power
P= W/t
t=Money
Money = Work/Knowledge so the less you know the more you make
That's pretty normal. The important point is if you get the job done on time and in a time frame considered reasonable. People aren't machines. No one works every second at their desk. It also leads to things like crunch time at the end though, time management is a tough thing for most people. Seems to be the nature of humans though.
Desk workers have it a lot better than assembly line workers, who are always 'on' when they are at their station, until they get their breaks.
Me, I hate clock watching, I don't pay attention to that sort of thing. I just do the job until its done within the required timeframe. But I am fortunate to have a job with a lot of different hats, so I have a large variety in what I do. I switched careers 8 years ago to get away from a job that required me to be at a desk all the time. Sitting at a desk all day is one of the most unhealthy things one can do to oneself.
The important thing is to balance and enjoy what you do. We really have no idea what happens when we die, there is a not-insignificant chance that there is no undying part of us. How do you want to spend your life? In fear of the clock and in guilt towards your employer, or have realistic expectations as a non-digital entity?
Work hard and put in long hours when its warranted. Relax when you need to. Don't kill yourself or you'll burn out quickly and end up quitting anyway. Any excessive exertion will have to be made up for anyhow. It's like sleep - the debt accumulates, you will lose productivity later if you go overboard now. Zero sum game. Have fun, enjoy life, work well, be productive. Work smarter, not harder. Etc.
He means actual coding sir. He said not reading specifications, meetings, etc. You know, the majority of the actual work being done in software development? Simple fact is we do little coding when compared to the other aspects of the job. That's why I tell kids coming out of college with CS degrees - get ready to learn, again. Because if they think it's all coding they'll be sorely mistaken. I spend more time trying to work with customers learning the domain and getting what they need out of them then I do actual coding. Meetings are required but sometimes lengthy. Documentation takes little brain power but is also required. Deployments are not very exciting but again, required. QA processes can be tedious too. Etc. I do spend some days coding non-stop from 9am-6pm but that's not typical, that's a spectacular day when it comes around.
That all being said, I do find myself working in a sprinting fashion as the posted does. I'll always be coding when it's time but sometimes you get a burst of speed and intelligence that you might not have every single day and you sprint ahead and make up for the times when you're not so sharp. This cycle goes on and on and it's hard for me to get around it. For instance, I had a burst of inspiration on Sunday and had more productivity in that off day then the entire week previous.
I defy anyone to focus day in and day out for years and maintain absolute focus at maximum productivity. If you can do that then you're a better developer than me and perhaps a robot.
A lot of programmers do that, actually. Programming is hard, and it's easy to get distracted. This is why if you learn to focus you can easily accomplish more in 8 hours than the average programmer does in 10. If you ever talk to people who put in 12 hour days, you'll find they usually waste a good portion of those hours.
Qxe4
I'm working, really!
but usually I only GET to about 10-15 hours, and spend the rest of my time dealing with meetings, documentation, etc. Coding is the fun part.
In Soviet Russia jokes are formulaic and decidedly non-humorous.
I'd rather work in his job than yours
Unless you actually enjoy your work. I would prefer working many hours in a project I enjoy because I really like coding.
But I think both OP and GP are a bit extreme. Working 10 hour weeks yet be paid full 40 hour weeks sounds cheap, but just resting 10 minutes in a full 8 hours seems like too much work and no rest, which will burn you down pretty quickly.
"I see undead people" Warcraft III - Necromancer
I'm in a very similar position. Coding something that is not interesting with a boss that hovers over me and thinks my productivity goes up if I spend an hour a day in meetings with her (she is not tech-saavy by any means and lacks any understanding of program developing). I'm pretty good at forcing myself to work, but end up with 45-50 minutes of good work in an hour. I chalk it up to the Yerkes-Dodson Law ( http://en.wikipedia.org/wiki/Yerkes%E2%80%93Dodson_law ) which basically says productivity has an inverse-U shape as a function of creativity. If you're a grunt adding receipts you need pressure on you to do your job and get anything done, but if you are asked to solve a problem creatively using a computer (e.g. most software development--the path to the finished version is not always explicit), high pressure from above makes productivity go way down.
Sorry you to hear you get "interrupted a few times per day" while Facebooking. You poor, poor thing.
Have you any idea how difficult it is to harvest your crops in only 30 hours a week?
You said you usually work about 10-15 hours per week. So that means that on some weeks, you fuck off on the internet for 30 hours a week!?! Sorry you to hear you get "interrupted a few times per day" while Facebooking. You poor, poor thing.
We need to get away from this paradigm of "You must work 40 hours a week" to the paradigm of "You must do this, this, and this for me and I will pay you X." Sometimes we work the full 40, sometimes we work more, sometimes we work less -- the important part is delivering to your employer what he wants. Clearly, asker is doing that or he wouldn't be employed.
I subscribe to the "As long as you're not illegally gambling or moonlighting from your desk, and as long as you're getting me what I need and not bothering anyone else, screw around on the Web as much as you want."
"Am I normal or stealing?"
No.
I think the very concept of "stealing" time is arse-backwards. I don't care or count how many hours my team puts in. I judge them by what they do: how many tasks or projects they complete, and how much help they needed. If anybody seems easily able to deal with their workload, I give them more challenging tasks. And if they complete those too, I use that to justify a raise at the end of the year (theirs, not mine).
If an above-average guy only does an average amount of work and spends half his time web-surfing, that's no reason to fire him. But he'll only get an average review.
That's my system, and I think it's fair.
I've worked a number of places (sales, factory, desk jobs etc.) and at all of them I've seen people spend way less time doing "work" than the amount of time they were at the job site. Some examples:
Now I work in a lab and teach (I've always been a biologist, just not always employed as one) and my lab mates give me crap for the little amount of time I actually spend in the lab. They'll be here from 8 in the morning to 7 or 8 at night, and I'm usually here 9-5. The difference is that I multitask, while they tend to do one thing at a time. So if I have some PCR or a gel or something running, I'll start doing something else at the same time, staggering them so that I'm always doing something and, hopefully, when I finish with one thing, the next is about ready to be worked on. Or I'll read, write, or grade papers, things like that. I end up getting more work done in my 9 hours on site than they do in their 11 or 12. Luckily my boss has figured it out and lets me basically come and go as I please, as long as I give him good results, but everyone gets so worked up about face time that there have been multiple complaints.
I say, as long as your work is getting done, who cares how long it takes. If you're programming 15 hours a week and getting it done, more power to you. Just because someone else takes longer to do the same task doesn't make them any more valuable as an employee. Actually, assuming you're more efficient than them, it makes you more valuable, in my eyes.
Oh, and by the way, I'm on my daily 10 minute break. Back to actual work for me. Have a nice 8 hour day doing.....whatever it is you do.
You sound terribly mismanaged, and understandably a little bit bitter about it.
Let me tell you something. Best managers view programmers as black boxes. Work requests go in, work comes out. If work>=schedule, then you have a good programmer and that's that. Doesn't matter if he plays Tetris 39 hours a week. If the project gets done, done right, on schedule - why would you care about anything else?
The worst managers are micro managing nitwits like the one you work for. Seriously, he has a stopwatch and is timing your one single ten minute break? If you take an extra minute or two do you get written up or talked to? Sounds like kindergarten to me. No thanks.
Look around some. You might just find a job that doesn't make you die of hypertension by your 50th birthday. They do exist, you know. You can work, put in good solid days and make good product - and not be treated like a member of a chain gang.
Weaselmancer
rediculous.
This job fulfilling in creative way. Such a load of crap.
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.
That 8 hour stuff isn't possible. How many 17:30 meetings have you been in, or 08:00 corporate town halls? If you work hard for your 40, you'll just be taken advantage of.
Hoist Number One and Number Six.
Is it okay for you to hire a gardener for 20 hours of work and have him actually work 10 hours and take a break for 10 hours?
Some people may feel that that analogy doesn't have any bearing cause its not in an IT field. Say, if you decide to hire a web design consultant, would you be okay with paying him out of your own pocket for a 40 hour week if it includes surfing the web, chatting with friends over the phone, taking long lunches etc?
This doesn't mean you need to chain someone down to their job and certainly taking small breaks throughout the day is needed just to mentally refocus, but if you don't feel comfortable paying someone 40 hours for 20 hours of work, why would an employer be okay about it?
Food for thought.
If you're actually writing code more than 50% of your time you aren't thinking enough to warrant anything beside grunt programmer work. Good solutions require research and thought and if you aren't thinking and just coding, you're writing sub-standard code. That said if you aren't architecting anything, if you aren't actually designing solutions, there's no reason you can't stay on task for 40 hours, plenty of people do.
Personally, I'm of the mindset that good solutions need to percolate. So I'll keep multiple projects going at any given time, and break up the work an any one of them to minimize true down time, and read slashdot during compile/debug cycles. But that's just me.
-- Adam McCormick
I always found that I coded in sprints. I could get more accomplished in one sprint than in the three days prior. Programming often seems to be a thing of get stuck on some stupid issue totally separate from logic and design (the aspects of programming I enjoy) and finally getting through that stop gap and getting the rest of the code completed.
I've also found that many times that sprint occurs around 4pm-5pm (yes, when everyone else start going home). This has convinced me that we'd be better off if we offered programmers the option of working three 12 hour days. Such would facilitate longer sprints, and during periods of times with less distractions.
As I like to tell people when they interrupt me, it takes about 15 minutes to get back into a task. Every time they interrupt me, that counter is reset. So when they come by every half hour to see how well I'm making progress, that means it's taking twice as long. Being that they keep doing it and I expect an interruption every 30 minutes, I stop at about 20 minutes (5 minutes of productivity) and prepare a report of what I've accomplished.
So, in 8 hours, I may accomplish 1.5 hours of work.
Some employers and staff understand this. I end up coming in at my own time (usually around noon), spend the first few hours taking input and answering questions about the progress, and then around 5 I dedicate myself to work until midnight. So 5 hours of chitchat and minimal on-task work, and 7 hours of serious uninterrupted work.
So 7.5 hours vs 35 hours of accomplished work. Which is more advantageous to the company? Quite often I've accomplished a week long task in a single night.
At one employer, they asked me to modify a partially completed application for a new client with new specifications. This was on Friday at 4pm, and was required by Monday morning. They were specific down to what font, size, and layout of the GUI. I said it would take a month or so. They didn't like my answer, so they got the lead developer from the project who talked in circles and finally said it would take a few months if he put his entire team on it. I came back with "I can start from scratch and have it done by Monday morning, but don't expect me to come in til after noon, and no one is allowed to call me all weekend. I'll initiate any necessary communication.". They said it was impossible for me to do that, it took the original team two years to get it to this point. I worked all weekend by myself at home, and at 6am Monday I sent them the finished product.
1 sysadmin who does development for fun 1 weekend vs a team of developers for two years. Hrm. My code was only a few thousand lines. Theirs was a few hundred thousand lines. I considered taking some of their code to use in mine, but it was so chaotic and poorly written that I would have spent the whole weekend reviewing it and fixing it.
The customer was happy, but the boss was pissed at me for some reason. And I was a salary employee, so they didn't even pay me anything extra. The sad part was, it also served almost all the functions of our primary product, which didn't always work right. There was lots of "but you didn't do it this way.", which I followed up with "but this is better, faster, more robust, and made the customer happier."
They fired me a few months later for an arbitrary reason to get me out. Go figure. I think they gave me the impossible task to accomplish in a weekend so I would fail and they could fire me for it. I was given a few other "impossible" tasks, which I accomplished also, before they finally just got rid of me. Hmmm, I did more than the entire development group, by myself, with easy to understand and manipulate code, and they weren't happy.
Serious? Seriousness is well above my pay grade.
Comment removed based on user account deletion
UML isn't a programming language. It's a way of drawing out an architecture. There's some tools out there that can convert it into code (which is trivial really) that some PHBs think are the best thing since sliced bread, but most use of UML is to show interactions between classes in quick freeform drawings. And very few of those use strict UML- they tend to be the same handwavey drawings we've been doing on legal pads and whiteboards for 30 years.
I still have more fans than freaks. WTF is wrong with you people?
If the project gets done, done right, on schedule - why would you care about anything else?
I agree. Where I work the head of IT moved up "from the ranks" and even lends a hand fixing bugs in the code when he gets a chance. But he knows his primary job is basically to run interference. I've seen it--it's ugly. Lots of time spent on the phone, hashing out specifications and requirements in looooong, boring-ass meetings. No thank you. And when things get to us, he trusts us to leave us to our devices and get the work done on time.
It's a pretty good trade-off.
To answer the original question...
How many hours a week should a full-time programmer program?
Should? I would say the answer is that there is no answer. What you should or I should do varies greatly depending on our personalities, our likes and dislikes. I like to build things. I enjoy solving problems. 40 hours a week doing what I enjoy is easy.
Slackers.
I generally code for 172 hours a week. (It helps if you constantly travel West at a slow rate. Yeah, every few weeks, you'll lose 23 hours, but that's your vacation time.)
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
UML isn't about programming. It's about documentation for large projects that require division of labour. It's about specifying functionality for communication between business experts and the people who get the work done. It's about getting the big picture without having to pour over the whole picture with a magnifying glass (i.e. reading the source code).
Seriously, I might consider contributing to more open source projects with bug fixes if it didn't involve scanning though megabytes of code first to narrow down the source of the problem.
Something that I think Sourceforge or an equivalent repository system really needs is a tool for reverse/round-trip engineering UML diagrams of the projects it contains (i.e. identifying how/where code restructuring affects UML documentation and supporting the update of that documentation). One reason why nobody has actually tackled this may be that Sourceforge projects may contain various combinations of Java, C++, python, C, PHP, perl, etc and UML really works best with object-oriented languages.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
I'm experiencing something similar, although, I must say it's not the "coding" that kills me, but the amount of context-switching I'm forced to do on a daily basis.
First, just let me explain my work. I'm the only developer in a technical department of 15 people, in a small local branch of a much bigger company. As such, I serve both various developing needs of my local department, as well as other departments in my branch, most support-systems for first, second and third-line support staff, as well as a multitude of network partners. Except for the development duties, there's an emphasis on last-line support, IP-networking, and product management.
What I've discovered, is that the single largest mental challenge for me, is being forced to radical context-switches, often without advanced warning, and many, many times a day. One minute, I may be working with low-level IP-protocol-debugging in hex-dumps and bit-masks, and 5-minutes later supporting the operational staff with ongoing database-issues, 15-minutes later forced into a spontaneous meeting about human-resources content-managment problems in the customer-support systems, being interupted by another scheduled meeting about conceptual architecture and product management.
All the individual context-switches is what really hurts me. I've reached a point when whenever a colleague shows up, or whenever the next bug is in a different system than the last, I almost experience physical pain, and mental pictures of a harddrive about to give up, trying to chug in those long-gone swap-pages.
You mention "maintaining a couple of dozen web apps"? Even if the technologies may or may not vary much for you, is it possible that the context and nature of the different apps are much varying, giving you a similar problem to mine? That is, forced to "switch project" often, and spending a lot of time and energy on trying to remember the relevant details for the next bug on the list?
Otherwise, when circumstances allow, I try to work from home, turn off the cellphone and shield myself off, in order to concentrate on that specific project. With all the context-switching gone I usually don't have a problem spending at least 25-30H/week doing serious "coding" (including design. development-oriented QA, test-cases, careful versioning), more for mundane typing-heavy projects, and less for more demanding designs, either due to unusual requirements, really tricky algorithms, or simply big complex stuff.
For challenging projects however, there's certainly a "burstiness" to the productivity. Some problems simply needs to be processed "offline" for a while, before they can be solved, but I think that goes for any mentally challenging activity for anyone. Most people I talk to tells me that they solve problems best while sleeping, so maybe you should find someplace to hide for a nap during the workday? ;)
No, perfectly serious. Problem is you're assuming a constant workload and a perfect equivalence between workers.
Although I'm a coder we are often put as "leads" in projects. Think "manager lite". And I did put a guy on a team I was leading who mostly plays Tetris. And sleeps in his cube.
The thing is - he knows more about the system than I do. Way more. The task I gave him took him an afternoon. Would have taken me two weeks, minimum. He banged it out, it worked perfectly, he went back to his Tetris. I'm happy, he's happy, my manager is happy we made the schedule, the customer is happy.
We're all happy so I don't see a problem.
I work more than he does, sure. But only because I have to. I'm not as good. I don't begrudge him one single bit.
Weaselmancer
rediculous.
If you go by the metric that, in the typical large project, the resulting product ends up with 10 to 100 "lines of code" per person per day, hey, most programmer's probably took about 15 minutes to type that in if you exclude all thinking (reading, studying, daydreaming while unconsciously problem solving, etc.) and meeting time.
this is the work cycle. Once you need to do something, you generally need to hatch an idea. and hatching is not always active. it can be passive too. while stupidly surfing or even doing your laundry at home, your mind can be busy with the issue in the background. in that respect, coding is a kind of work that generally intrudes one's personal and leisure time. and you cant rest until you actually devised a solution to the issue. when you feel that something clicked, your mind rests in ease, and you can function normal again. and you can start implementing the solution. that is the coding phase. of course, until the next problem is put forth. then the cycle begins.
resting is time that happens in between all those. whether you code or think for 15 minutes and then surf or just be stupid for 5 minutes, or while resting on weekend you cool off the engine.
you gotta cool off the engine. be warned. if you dont and just keep thinking and coding like a monkey for months, you will eventually snap, regardless of how young you are. concentration takes huge toll on one's brain.
so, act wise. dont feel that you are 'stealing'.
Read radical news here
I'm biased because it's a hobby of mine, but yes, I could see doing that if the break allows for thinking about drought resistant perennials, planning so that the garden has some interesting blooms each month, and thinking about how to get rid of some bugs that other gardeners are succumbing to. Then again, gardening is a pretty good activity to think while working. As an aside, and it may be observation bias, but I do know quite a few long time programmers who do get into gardening for the mental challenges (we had some folks at the Tech Shop/Maker Fair working on wireless soil sensor equipment).
An old manager told me once that they were told in a seminar that they should expect 4-5 hours per day "real work" and the rest crap from most engineers. You are always going to be interrupted with random stuff-- answering email going to find someone to have a mini work meeting etc. I find that this is pretty normal. I myself can't do more than 4 hours without being extremely burned out at the end of the day.
Indeed it will burn you down.
I just did a 3month stint of constantly long days, not "insane" like 90hrs a week, but sprinting upto 60hrs a week, a minimum of 43hrs a week. I was lucky to have single 10minute break apart from smoke breaks, which aren't really breaks as your brain is still churning at almost 100% speed. Before that 3month i had 1 week of for christmas by knowing that i have to work 12hr days after i get back, and had been working a huge sprint for 3months.
best of it at all was i was promised a raise, but basicly told to f* off. I walked and they are in so deep shit now, their clients keep calling me as they can't get shit done. they are already about 4 weeks late of a simple transfer over of VMs task alone.
Also they had to hire atleast 2 full time guys and put some of my work to 3 others. And all of that because they refused to pay even industry average ... Now instead of paying me the well deserved 30% more (yes i was THAT underpaid), they have to actually pay atleast 130% more, maybe more like 250% more. But hey, all's good, they bill by the hour afterall, so when the no-clue goons are working they actually get more as they spend more time. That's competitive business, riiiiight? ;P
Pulsed Media Seedboxes
Are a workaholic. And you can never get enough workahol.
Science advances one funeral at a time- Max Planck
>They fired me a few months later for an arbitrary reason to get me out. Go figure.
That's easy : think of the manager who sold those thousands of hours of work (though pollution would be a more appropriate description, but I digress) to the customer.
Now, someone like you comes in, shows his utter uselessness as leader, and threatens to destroy the only motive for his existence, which is a biiiiig team of developper with a huge billing rate. All he wants now is to get rid of you.
One way out of this is for you to work freelance, if you can. Just remember to multiply your coding time by at least three, so your bills won't be ridiculously low, plus you'll need the time for the paperwork anyway.
To those doing all the UML bashing...
Have you ever used it, or more to the point, have you ever used it properly ?
I find it hard to believe that anyone with any experience with it at all would take that stand. It's not because I think it's particularly easier to create a complex object oriented design using diagrams - that depends more on the particular project as well as the experience of the developer. No, the real reason I find it indispensable is that (unlike apparently some of the bashers here) I have to communicate my designs to people that are not software engineers (i.e. customers, managers,etc.). These folks may not even understand the language I'm developing in - or care, but if I've done a good job, they can understand the diagrams.
That macho "real programmers don't use UML" crap doesn't fly with me, and I've been around long enough to have used Rumbaugh, Booch and Fusion before it became UML.
Real programmers (at least any that I would employ) use whatever is the most efficient tool for the given task. You can keep you're "I only program using vi" attitude and get washed out by a college grad or offshore resource willing to work for a fraction of your rate who understands the basic principle that for a design to be good it must be comprehensible by someone besides the designer.
Now get off my lawn!
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
So can my stack of 4x6 index cards. It might be old school, but it works, and I can wrap a rubber band around the stack, throw it in a drawer, and forget about it until I need it.