4 ms·
No, I'm not, and it's one of the things I enjoy about programming. Some weeks I work 30 hours, others I work 60. But if I did the things I committed to doing
by keypusher 12y ago
No, I'm not, and it's one of the things I enjoy about programming. Some weeks I work 30 hours, others I work 60. But if I did the things I committed to doing this week, then I go home. Why sit in the office and pretend to be working? It makes no sense.
- AndrewKemendo 12y ago>Why sit in the office and pretend to be working? It makes no sense. Only if you think of it from the "accomplishing tasks" perspective. For example where I work, we are there even if we are not actively working to be available in case we need to immediately respond to demands of leadership. For example this week I had to answer an off the wall question about our project that they needed an answer to RIGHT NOW because they have a meeting with their boss in 15 minutes and anticipate that their boss would ask that question. Yea.
- stingraycharles 12y agoUsually phones work fine in emergency situations like that.
- pavel_lishin 12y agoShould your leadership be aware of the answer to the potential question without having to ask you about it 15 minutes before the meeting? This seems like something that ought not be a problem, if your leadership is attending standups and there's clear communication.
- shawn-furyan 12y agoI agree. This is an organizational issue, not a legitimate job duty, irrespective of whether the rank and file should be allowed to leave when they've finished their work.
- paulhauggis 12y agoMost managers would not accept this. Since most developers are paid salary (as opposed to hourly), many feel like if you were leaving early, you aren't working hard enough. I've seen it at every place I've ever worked. At one place, my manager directly told me I needed to stay until 6 or 7 every night or the boss will think that I'm slacking.
- pscsbs 12y agoThat's shocking. No manager I've ever worked for had this kind of mentality. If you needed to show up late or leave early, as long as you were getting your tasks done for the week, it was fine. Forcing people to stay until 6 or 7 is the fastest way to get developers to burn out.
- m_gloeckl 12y agoI'm in the same boat. Some weeks I simply do not have enough work to fill the 40 hours I should work according to my contract. I'm just sitting around, looking busy, and billing those hours to the project I'm assigned to. If I report fewer hours than that I'm in trouble, because my billable hours go down and that means I'm getting a smaller bonus at the end of the fiscal year.. Yeah, the system isn't really working.
- MikeTLive 12y agothat is a perspective issue - my salary is annually negotiated , in compensation for an idea of what work will come up and how i will better myself and the company. It is not how many hours worked in a week. I don't get a "weekly" salary. having this different perspective in mind allows acceptance of the time shifting that comes along with knowledge work - inventing and creating are not on a linear scale.
- keypusher 12y agoThat seems completely backwards. You are being paid salary but treated as if you were hourly. If your managers think it's important for you to be in the office 9-5 every day, why don't they just set up an hourly rate and make you punch a timecard? To me, the reason to have salary is that you are paying a worker to do a job. Highly paying jobs usually require highly skilled workers, and those workers should be judged on their results. Completion of the job and all of its duties is worth $XXX,000 per year, and it is up to the employee to determine how best to allocate their time and resources. The fundamental mistake of the approach you describe is that software development is not a profession in which merely showing up and putting in labor is of great value. I can pay Jim the Janitor $10/hour to show up and sit in front of a computer. He is never going to write me a distributed map-reduce powered vectorized graph search in Erlang (or whatever). Let's say my boss tells me to write a TPS report collector. So I come in for 10 hours every day for a month and slave away on a bunch of crufty repetitive boilerplate code which is low on creativity and high on required hours. I eventually manage to hack together a custom report finder and parser, and generate the necessary solution as described by his email. What if my coworker wakes up after a good night's sleep, comes into the office and talks to everyone involved about the project, then realizes that what the VP of MarketResources really wants is some nice graphs of the TPS trends? He finds an open source TPS report analysis framework, spends a couple days integrating it into the workflow, learns a great solution for dynamically generating graphs while out for drinks after a local dev meetup, submits it all to the boss after two weeks and then takes a vacation. Who has really provided more value to the company here? My point isn't about frameworks vs custom software, it's about good solutions to hard problems. Salary employees, especially software developers, should be evaluated on their ability to come up with great solutions to hard problems and provide value to the team and company. Not whether they showed up at 7am or 10am. Programming is not like digging a ditch, where 17 man hours are required to dig a ditch of length 14 and width 5. It is quite possible and even common to spend a lot of time working on widgets, features, and implementations which are completely unnecessary, non-optimal, or completely wrong. It is well understood that one great programmer can be worth many, many novice programmers because even 20 novice programmers given twice the time will not come up with the brilliantly simple and elegant solution of the veteran expert. So the more you can do to make the programmers you do have happy and as effective as possible, the better.