431
How do you deduce they are not working?
As a junior I typed all day, hacking away at my code, with just 20 minutes for lunch.
The more "senior" I got, the less time I spent typing and the more time I spent thinking.
If I "stare at the ceiling" and my producer walks into the room,
she starts to smile, because she knows in half an hour I will have solved a ...
226
Many companies are certifiably insane around this.
Seriously. If you asked 10,000 tech mangers, "Let's say you paid Danica Patrick $100,000,000. Do you think she could win the Indianapolis 500 by riding a bicycle?", I'm sure not one of them would say, "Yes."
And yet a good percentage of these same managers seem to think that highly-paid software developers ...
190
My response would be to say "I'm a little busy right now, can you email me and I'll deal with it later". Chances are some of his questions are legitimate, by forcing him to email you it doesn't interrupt your flow and he is unlikely to bother detailing the problem in an email if its trivial. You then also have a record to show to management if his questions ...
178
From The Pragmatic Programmer, Tip #8 "Invest Regularly in Your Knowledge Portfolio":
Learn at least one new language every year. Different languages
solve the same problems in different ways. By learning several different
approaches, you can help broaden your thinking and avoid
getting stuck in a rut. Additionally, learning many languages is far
...
170
I would suggest that, in reality, one cost is visible and quantifiable, while the other cost is neither.
If failing to upgrade the hardware bleeds even as much as $1000 per developer per week from the budget, no one outside (read: above) the tech department ever sees that. Work still gets done, just at a slower rate. Even in the tech department, calculating ...
152
good code that only can do A is worse than bad code that can do A, B, C, D.
This smells to me like speculative generality. Without knowing (or at least being reasonably sure) that your clients are gonna need features B, C and D, you are just unnecessarily overcomplicating your design. More complex code is harder to understand and maintain in the long run. ...
148
The later you test, the more it costs to write tests.
The longer a bug lives, the more expensive it is to fix.
The law of diminishing returns ensures you can test yourself into oblivion trying to ensure there are no bugs.
Buddha taught the wisdom of the middle path. Tests are good. There is such a thing as too much of a good thing. The key is being ...
145
Sounds like it would do more harm than good. Ignoring for a moment whether it is fair for a manager to do that, let's look at the logistics...
Problem 1: Are all bugs created equal?
Developer 1 introduces a bug: Erases all customer data and curses at them.
Developer 2 introduces two bugs: Form labels are not left aligned, and the calendaring feature is off ...
136
Run away, run very, very far away. And fast.
You can try to talk to your boss about the situation, but from what you've written, it sounds like there's a fundamental lack of understanding about the importance to programmers of communication with outside resources, general collaboration, and just taking your mind off your work for a minute or two. Frankly, ...
124
I feel like I am staring into a mirror of me from seven years ago...I will share with you my experience.
I was in a position like yours. Within a year I was senior level at the company I was at and I seemed to be churning out code twice as fast as everyone there. This went on for another couple of years before I got bored.
I then went on to a much, ...
117
I wrote a little commandline utility called 'alert' which will cause the computer to beep / play a sound / etc. Then, when I have a lengthy command to run such as a make, I run make; alert. Where I can, I will also have it take an argument so it makes a different sound depending on the argument. Thus I can do make; alert $? and I'll know a) the build is ...
115
It Happens
Unfortunately we don't always get the credit we deserve, or management will give credit to the people directly under them, who do not necessarily have the power (or honesty) to bestow some of it upon you. It's an organizational thing: by way of the organigram, it should trickle down; except a few people act as dams.
I'm afraid that's what ...
111
I agree with the rest of the answers but to answer the what is the time difference question directly.
Roy Osherove in his book The Art of Unit Testing, Second Edition page 200 did a case study of implementing similarly sized projects with similar teams (skill wise) for two different clients where one team did testing while the other one did not.
His ...
104
I have the same problem, and the solution for me has been to spend the time doing something which will not get you sucked in. For me, this is usually either (1) filling up a water bottle, or (2) standing up and taking a 30-second walk around the office to stretch my legs, which need the movement anyway. You can get lost browsing the internet; you rarely get ...
102
Personally, I would want the company to just sort out the equipment I need, not give me a budget and make me to deal with all the research, negotiation and other hassle that goes into buying and installing corporate hardware.
In the end, all I want to have to do about hardware is state my few requirements, and have someone else do all of that work, so ...
98
I actually think it's a pretty close call. Both dynamic typing and static typing have their advantages.
Reasons for dynamic typing being more productive:
It's more concise - A lot of extraneous boilerplate code can be removed if everything is dynamically typed - type declarations, typecasting logic etc. All other things being equal, shorter code is ...
95
I will put my 2 cents in here from the employer's side ... who is also a developer.
I agree that low end machines are useless but top end machines are overkill.
There are a number of reasons why you don't get the top end machines:
Cashflow is a real issue, not just a theory. You might be getting paid $60K-$80K per year, but this month we have a total ...
92
A genuinely terrible programmer can have sub-zero productivity (the bugs they introduce take longer to fix than it would take to just do all of their work for them).
And a genuinely great programmer can do things that poor and average programmers would simply never achieve, regardless of how much time you gave them.
So for these reasons, it's hard to talk ...
90
Thinking about these things is definitely good, but don't let it stop your progress.
One approach that works really well (especially with iterative development) is to implement a simple solution and then refactor as necessary later. This keeps the code as simple as possible, and avoids over-engineering. Most of the performance or architecture changes you ...
89
Once we were halfway the project, the PM stated we had to use third party message queue capabilities instead of threads and had to implement load balancing
This isn't an appropriate thing for a PM to "state" unilaterally. Two reasons:
Design decisions should be made by a technical resource and only in response to NFRs. So politely ask your PM if there is a ...
87
Anecdote time:
I've had two developers work for me who leaned towards over-engineering in this manner.
For one of them, this basically ground his productivity to a halt, especially when starting up a new project. Most especially if the project was, by its nature, fairly simple. Ultimately a piece of software that works now is what we need. This got so bad ...
81
I research most problems I encounter.
If I encounter an issue, my first assumption is that I am not the first one to have encountered it.
I also don't believe in reinventing the wheel - so will look for an existing solution before writing my own.
The thing about research is that you need to evaluate the results and how well they fit (or not) with your ...
80
In my experience, the answer is sadly no. I've lost many jobs due to my wanting to push a culture of craftsmanship over sloppy hacks, design patterns over procedural code written as object-oriented, and embracing new technology over staying with obsolete legacy tech. Note that I don't regret those choices, but the reality is that very few of our developer ...
80
Why do people climb Mt. Everest? Or run 100 Miles in 24 hours? Why do we undertake any challenge? Because it's there. I see nothing wrong with "Ars gratia artis". There comes a point where learning for learning's sake becomes it's own reward. But if you want more powerful reasons to learn a new language here are some:
New ways to solve problems
Learning a ...
79
I had no prior experience when I interviewed
This sounds like it is your first job in the corporate world.
I like having IRC open to talk in a few different rooms during the day and keep in touch with friends/family over IM
Don't do this. There are a lot of companies who work in regulated industries where IM is totally banned. There is a time for ...
79
During my last project, I used to have the same problem. I was thinking about the code during my commutes to home, before going to sleep and even as I was alone in the room with my girlfriend.
That's when I knew I had to stop.
I have pretty much figured it out now, and here's my advice to you.
Get Positive
First, accept that you can't just stop thinking ...
79
Quit. No, not your job! Just get up and go home. You're done for the day or the weekend. 19 times out of 20 when you come back to the problem next, the solution will present itself within an hour.
77
Simply No. Coding for 36 hours has nothing to do with programming, rather it's an attribute of human. Very few people can stay awake for 24 hours and even when they stay awake, their mind really loses problem-solving skills. Drivers who are sleepy, simply hit other cars. Accountants who are sleepy, simply make mistakes in their calculations. Also many ...
71
Most people are content with their pay check and do just enough to not get fired.
Only top voted, non community-wiki answers of a minimum length are eligible
