As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Working with software day-to-day usually means you have to juggle project work, meetings, calls and other interrupts.
What single technique, trick, or tool do you find most useful in managing your time?
How do you stay focused?
What is your single biggest distraction from your work?
The trick the Getting Things Done system teaches is to have a trusted system you can put action items into. That way you don't have to keep "juggling". To keep with the metaphor, you can put the other balls down and have confidence that they will not be forgotten. Then you can concentrate on a single ball at a time. There are many, many other excellent tricks GTD teaches. Well worth getting the book.
I read this rule somewhere, and I use it every day...
If someone asks you to do something - if it takes less than 2 minutes, do it immediately. If it takes longer, put it on your list and come back to it.
This really works for me.
You should see this:
Randy Pausch Lecture: Time Management
It's a teacher from Carnegie Mellon who is near dying, giving his final lecture about time management. It's the best tips and tricks you can find.
To manage the general mayhem of the job, I try to use a toned down version of GTD focusing mainly on trying to maintain Inbox Zero and pushing tasks into a todo list (I use Remember the Milk for task list management).
As for maintaining flow in spite of interruptions, leaving a TDD project in a state where tests are failing tends to give you a place to jump right back in when you come back from a meeting or other interruption. Leaving a batch of uncommitted changes might serve a similar purpose -- to get your mind instantly back into the flow of the project without having to go look around to remind yourself what state things are in. Beyond that, using a fairly detailed task list for the projects at hand can help keep you on task and moving forward.
Often times, I've found my manager's manager to be the biggest distraction! :-) He likes to feel plugged in to the day-to-day work of his dev teams and frequently comes around on "walk-abouts" to see how things are going.
I find email the most distracting, so I've really cracked down on receiving certain types of email. I've unsubscribed from many mailing lists, job alerts etc. Shutting down email for a period of the day is quite useful too.
I enjoy going to the library. The quiet but busy, concentrated atmosphere basically forces you to work. The change of venue also seems to shut out some of the busyness and maybe worries you have in day-to-day life.
I use most of ZTD (http://zenhabits.net/2007/11/zen-to-done-the-simple-productivity-e-book/). GTD is too sophisticated and to big for me.
Basically, I make lists of tasks. Every morning I select three which I really need to do that day. I work on them until they're done. I struggle not to get dragged to other things.
In an office, I sometimes book a conference room and work there, distraction free. I emerge from the lair when I'm finished with the three most important tasks.
Encourage people to push their correspondence with you down the distraction chain:
Phone / Face-to-face
Instant messaging
Email
You can do this by deffering them: "I'm really busy right now, can you send me it in an email?"
This should reduce the amount of interruptions you receive allowing you to stay "in the zone" for longer periods of time, increasing your productivity.
Finally, allot time for processing emails at set times of the day. I, for example, have my email set to send and receive once every two hours. This bulking of activities allows you to get more done in the day without impacting customer relations.
My single biggest distraction is myself - I tend to go all hare-brained, chasing emails and internet links much of the time. Therefore, I'm using a simple trick to discipline myself into staying focused and on-task for larger parts of the day. The principle is to stay accountable for the use of my time:
1) Have a scheduled job in your operating system, that pops up a small messagebox every 15 minutes (in Windows, it should run the command C:\windows\system32\cmd.exe /C "start /B msg jpretori /W /V "15-minute check"")
2) Have IDailyDiary running in your system tray (a text file will work fine, too). Every time the box pops up, fill in what you've been up to the last 15 minutes.
I've caught myself with an ugly day filled with procrastination before... It's quite a good motivation to stay on-task.
Recently I've started using a great little free windows app called NextAction which you can get from here.
It's greatness comes from it's simplicity and it really helps to refocus and stay on track when dealing with all the days distractions ... email, co-workers, scrums, rss feeds, twitter, lunch, coffee breaks, etc. Having a list of what I'm working on always there on the desktop makes it very easy focus after any context switch.
Much better than pencil and paper, check it out for yourself.
NOTE: There is a more comprehensive web based 'NextAction' at code.google ... not so good for me, but maybe for others.
A single answer to all of the listed questions is David Ellen's Getting Things Done (GTD) ( "The Art of Stress-Free Productivity" )
A 45-minute presentation of the process can be found on youtube, and you can get the book on Amazon
Also you could think about the kind of things which make you want to browse the net, check your email, etc. For example, if a build I'm working on is taking too long my mind will wander.
So it actually pays off to make the build process as quick and efficient as you can make it, so you can make changes and test quickly.
I also find it helps to get enough sleep (tiredness is bad for concentration) and not to drink too much caffeine (seriously. I feel so much better after cutting down the amount of caffeine I drink. Try naturally caffeine free teas!)
(I seem to have wandered slightly off-topic into concentration there... still, I find the better I can concentrate the better I will use time!)
If you want to improve something, you first have to measure it.
I like Rescuetime. It logs all applications and websites you visit and how much time you spend there. You can tag applications/websites, i. e. with "work", "waste", "news" and get nice charts, productivity measures etc.
I find that http://www.rescuetime.com/ lets me know what I was actually doing all day, rather than what I THINK I was doing!
It also lets you put a "productive" level on each process/website you run or do so you can see how productive you are being.
The single most useful piece of time-management advice I could give is just get on and do it. If something is going to take less than 5 minutes to do, do it now.
Single most useful? http://www.nowdothis.com is AWESOME for focusing on what currrently needs to get done, and has raised my productivity by tons. (Bonus tip: Use Google Chrome to make it its own application and then make the app always be on top of other windows)
Biggest distraction? Google Reader.
(Slightly off-topic)
They says there is no such thing as time management. You can't manage an hour and get extra 20 mins out of it. Well, I recently discovered that you can. It you're listening to podcasts or watching recoded web casts, you can speed up the play speed. I found that it also helps me stay focused on the content rather than drifting off and starting check my email during the natural pauses. Then I saw Jeff's post on the same topic.
Email, IM, Skype... all those can distract. But biggest distraction is when my fellow colleague ask me why I wrote some year old algorithm this way and not that way. It brings my work to halt even if I know the answer.
To stop this interruptions, we have a 5-minute break every hour outside the office where we can talk about such problems.
There are a lot of things to do and I'm not sure you'll find any single technique to get organized and stay focused.
But...
Do list the things you have to do. Several short lists will be needed (today, later, inbox == to be sorted out, etc...). Review these lists once in the morning, and then in the evening. These related posts are worth a read: The Taste of the Day and The Trickle List
Timeboxing: allocate time in your calendar to get the tasks done
As suggested by harriyott, switching off email is kind of essential too!
This question has already been asked, so you might search for it.
I personally use Zen to done which is a simplified version of "Get Things Done". For the trusted system I host Tracks application for myself.
The best way to get through a big chunk of work while staying focused is to list your priorities on paper before you start. Trying to keep a big list in your head is a sure path to procrastination. Plus, it's a great feeling to tick off items as you finish them. Put on some music, close down your email, and get busy.
But then you have people trying to get your attention. Make sure your colleagues and clients know that you prefer to receive their queries in email rather than in person or by phone. Bugs go directly into the tracking system, without anyone having to tap you on the shoulder for each one. Sounds obvious, but stopping your work to discuss something for 5 minutes can sometimes cost you 30 minutes productivity by the time you are focused again.
You can find a great document about time management in Wouter van Oortmerssen (aka Aardappel, the developer of famouses Open Source games like cube and http://sauerbraten.org/ )
The article I'm talking about is this
I guess you're after something practical. What I do is keep my action items away from my work environment, it helps keep me focussed. I keep a pad next to my desk, I write down each action item for the day at the top and half way down start keeping notes. When I've finished a task I tick it off, anything not ticked can be carried over to the next day (if it's still relevant). Been using it for about 3 years, I find it keeps me productive and helps me remember things. I've tried all kinds of software solutions, nothing works better for me.
I have an old laptop that I remove the wireless card from and sit on a completely quiet room away from distractions. Whatever I can't get done without the internet is just leave until later. My biggest problem is that I gooel to find a solution and end up doing 30 minutes research on something a blogger has mentioned in passing. I still find it takes me a good hour before i get into the flow of not distracting myself.
On the 'how to stay focused', I think once you decide to close your email and put your phone on send, the next things to control are the sounds around you that might derail your thoughts. People talking, phones ringing, etc.
I have started putting the headphones on and surfing to http://www.simplynoise.com/. This is a noise generator that gives you the option of white, pink, or brown/red noise. It drowns out most of the audio distractions that often poke at my concentration.
Stay productive: When I'm working on a boring project and notice I don't do anything useful but reading news, I set a timer.
Simple enough, set your mobile on a 1-2 hour timer. Work during that period. When the timer rings, take a break and feel good about yourself :)
For some reason, this works (for me and a couple of other people I know)!
The single most valuable tool that I can recommend is a "todo" list.
This may take the form of a specialised app, gadget or pen and paper, however the most important thing to remember is that new tasks should be added to the bottom of the list and tasks to be started must be taken from the top - ie. don't cherry pick your tasks, as this will leave you with a task list full of time-consuming (and often boring) jobs that will begin to drag you down.
Possibly better for programmers than GTD is Time Management for System Administrators. Same basic principles (reduce interruptions, keep a list) but with a nerdier bent.
I close email and listen to soothing music. Of course, this tactic really is all about minimizing distractions.
The lecture of Randy is great, especially since he knows that he does not have much time left in this world.
Meetings are the biggest time wasters. Try to avoid them wherever you can.
I don't believe in those tools popping up every so often asking me what I'm currently doing. That's very distracting as well.
It might be good to make a time-log for for a couple of weeks, but just to understand where you are spending your time so you may be able to improve things.
I like the time management stuff by Steven Covey.
... and by the way I'm lecturer for time management for IEEE for Europe/Middle East and Africa.
Related
I'm working on some pet projects and generally I sit around my personal computer about 22:30 or 23:00 to code. But since I try to sleep about 24:00 I don't start coding and ending up reading articles, playing some games etc.
I don't feel like I can write decent code in an hour, because the project is quite big and I don't want to randomly or carelessly hack it. Even though I use TDD, most of the time stuff I'm doing is not straight forward which requires lots of testing before getting it right.
What's your approach to these kind of issues? Do you just code later when you got enough time or do you have a different approach which allows you to code just for 30 minutes and continue later?
I generally don't write lots of code until i have the time to do it. The reason is that for me to get effective takes focus and that takes a bit of time to be correctly focused. That said those 30min slots are great for
Writing more tests: nothing like trying to get to 100% code coverage, and it's not a big waste since you are investing
Research: I spend lots of time reading blogs, looking for frameworks I can use or tools. Spending 30min finding a framework that does 80% of a feature you need is much better than spending hours trying to code it. The other factor to this is that if you implement the framework and you find it is a bad fit you are better educated in the needs which means your development will be smoother.
Well my first thought was "use unit testing", but then I read you are already using this. But I still think it's the solution to your program.
Try to make your tests as small as possible and use the "1 assert per unit test" rule to create small atomic tests. You should be able to fix several of these small tests in a 30-minute session.
Here are some things you could try:
Don't sit near the computer. Instead, take a large piece of paper and go somewhere quiet. Think about what you want to accomplish. Write down interface ideas, detailed implementation. Make a list of questions you need to solve before you can go on.
Take off a week and code away. The ratio of getting-into-flow over flow-time is just too bad for 30 minutes.
Keep a log about what you do instead of coding. Observe your emotional state.
Go to bed early and try to have your pet coding session very early in the morning.
A small tip (that I use at work too) is to stop coding in the middle of something, with an obvious big red compile error waiting.
The next time you start working, the error will actually help you to remember what on earth you were doing.
While you are working on the small problem, the big picture clears up and then you can continue designing.
Developing with such short times is difficult, but you can still get something of that time. Unit testing is one. Writing down the interface of a class is another. While coding the real stuff will take much more time, these tasks are essentially a no-brainer, and they are just an exercise in typing.
So, my suggestion is: focus on small tasks that do not require thinking and concentration, and can be completed in the timespan you have.
Never worked for me, pet projects are usually too interesting and I end up working to late hours of the night or through a weekend.
I would suggest reconsidering your priorities - if all the time you have available is one hour late at night, maybe it's better to spend it on games, articles etc. Or just hanging out. When you have a bit more time, say a lazy Sunday, spend all the time at once and actually get the sense of accomplishing something that pet projects are supposed to give.
Here's what I do with my personal projects outside of work:
1) I try to give myself a good map of my project by planning it out on paper. I diagram all of my objects, data structures, and/or SQL tables and determine what basic functions and interactions between those components are necessary. I may write some actual code during this phase if the solution is obvious, but typically not.
2) Once the big picture is in place, I prioritize the most basic and critical elements. I also try to figure out which parts will be easier to write than others.
3) After priorities have been set I start working on the easiest and most critical parts first and work gradually towards the more complex and less important components. Breaking each task down into smaller parts tends to help. For example, I may design a database table first and the next day create a data interface class that controls interactions with that table.
4) Unit testing really helps me feel a sense of accomplishment, even if 30 minutes of effort only results in a few quality lines code.
5) Keep a change log, even if it isn't very detailed. I've found my change logs to be invaluable if I work on a big project in many short spurts over an extended period of time.
Those steps right there help me the most. In the end I am able to identify small chuncks of the project that can typically be completed in about 30-60 minutes. Of course, as a project develops, I usually have to re-evaluate something and go back to the beginning for a while when I discover I left something out of the planning phases. Sometimes I need to go a bit farther and give myself a time line with some deadlines and make sure I celebrate milestones with a personal reward. If you have a tendency of staying up till the wee hours of the morning, something I struggle with, I also suggest giving yourself a coding curfew as well. I also try to make sure my "coding computer" doesn't have many distractions on it, such as games.
There's always one more bug. If not, there's one more neat feature you can add, and THAT will add more bugs. Which is one reason why I think that the use of the phrase "All you have to do..." by anyone in (or using) IT should be a hanging offense.
I can cut down on how long my coding sessions last by doing trivial things, thinking things out while away from the keyboard (the shower is best - or while in bed at 4 a.m.) and by using lightweight environments such as script languages, but "quick" coding sessions are something I long ago gave up hope on.
Just shifting mental gears into the coding mode takes time, picking up the threads of where I was before takes time, discovering that my "quick and easy solution" was neither of the above takes time. Fixing my "quick and easy solution takes time, debugging - more time, and so forth.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My team (4 people) have just reached a major milestone in our development, putting us at about 2/3 finished, but I guess the stress has caught up to everyone and all the gears have ground to a near halt, progess is being made at 1/5 of the original speed. I wanted to ask the SO community how to best deal with this, I've identified the following problems.
Lack of clear focus and direction. We seem to be hitting small side improvements, but not working towards anything central to the project so I think that's causing a lack of enthusiasm.
Coming down off of a very strong development push. This seems to have made everyone want to really "relax" which is fine for a bit, but progress still needs to be made.
The remaining tasks are more tedious than glamorous. This is the nature of the beast but I have yet to tame it effectively.
Any help is appreciated.
Some downtime is necessary after reaching major milestones. People need to relax and decompress. Pushing on just carries the stress and fatigue forward and the team won't be working anywhere near their potential.
Give everyone a couple days to a week off and let them come back fully refreshed and ready to continue.
Tell them you only need 3 people to finish the project.
I think the key is when you say the remaining tasks are more tedious than glamorous. Yep life is like that but many developers don't want to work on tedious. None the less as the lead, it is your reponsibility to determine what tasks need to be done and assign them to people to do. Same as with the more interesting tasks, maybe even more important (someone will almost always step up to do the interesting stuff, not so much with the tedium).
So assign your tasks, give them their deadlines and follow-up on the progress they are making. If you have any of the more interesting tasks left, don't let anyone have one of those to do until he or she has completed his share of the tedium. In fact dangle the interesting tasks left as a reward for getting the tedium done faster or doing the most of it.
If you don't have any more interesting tasks left, thn maybe you can generate some competition to get the rest of the stuff done.
It's ok to be slack for a few days after a major push, but if it lasts more than a week, I think you need to get the team together and talk about what needs to done to fix the slacking.
Do something, other than work, as a team. Go to lunch, happy hour, laser tag, anything you can do as a group that is not work. A short break from stress can be a huge relief, and hopefully can reenergize your team for the final push.
I also strongly believe in "slackweek". If the deadline for the entire project isn't too close: just let everyone do what they want for a period of time. Could be write some tests here, align some stuff in the gui, read up on the latest in bla, whatever. Up to you if it has to be work on that specific project or just something useful overall.
THEN, you have a big "launch" meeting where you talk vision and goals for the remaining third - big picture stuff, and get everyone aligned again. I'm assuming the stuff left is really needed to give the customer a complete product so that it can be motivated for.
Good luck!
Add an easter egg! It doesn't improve the core project, but it helps give developers a sense of ownership.
Also, it can be helpful to set aside time for "pet peeve" cleanup. This gives developers a chance to fix nagging issues that are important to them. This helps improve the project, and at the same time allows the developer to make progress with something that is important to them. It helps keep the excitement level up.
Are there clear deadlines/milestones coming up soon? That would be something to consider as having a target date can help provide some focus.
The momentum being lost, does it tie back to people just being burned out, not as motivated as they were before or the work becoming much different, e.g. working out specifics on vague requirements rather than the cool parts that are done now?
One of the things Agile gets you is a finer focus on where you stand, what you've done, and what's left to do, within the next few weeks. There are concepts of "backlog" (what has to get done) and "velocity" (how fast are things getting done). Since each iteration is typically about a month, it's very clear to see when the team is not working at the projected/required rate, or working too hard. You might be able to borrow some concepts from Scrum for these purposes.
A more straightforward solution is to remind them that if they keep working at a reasonable pace, there's no end-of-milestone crunch time that makes everyone's life hell.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
While novice software designers expect their users to behave rationally, it's far from being the case ; I've seen many times the user perception being totally disconnected from reality, or it's feedback obviously irrational.
I think we are the one who should adapt, not the other way around.
There's only one way that I know of to achieve this : listen to users, especially about what they don't like in software they use.
If there's one thing I've learned so far ; they often complain about things one wouldn't expect
What unexpected things did you learn from your users?
A few years ago, hospitals (at least French hospitals) were run using old win 3.11 software’s. Every single task was tedious; moving someone from one room to another would take 5 minutes to an expert user
A friend of mine was working on selling up-to-date software to those people. The same simple task would take 30s to a total beginner.
While most of the users were very happy with the new software, a handful were complaining, which wasn’t a surprise (there’s always a handful of users complaining). What was more unexpected was their reason: the software was damn slow. “The same simple task was instantaneous, now it takes ages to achieve. Give me my old software back”, they would say.
My friend decided to meet them, and asked them for a live demo of the slowness they were complaining about.
“Look, said the user, with my old software : I input the first name, enter, the name, enter, the admission number, enter, the old room number,[…insert 5 minutes here…] the new room number enter … and it’s done….. See… Everything is instantaneous”
“Now, look at your software. I do a drag and drop, as you taught me. And I wait, I wait… look, it’s done..I’ve waited for almost 30s….”
That’s a real world example. It really happened. I’m pretty sure that if the software had been modified to ask for useless information that it would have discarded afterwards during the 30s period, this user would have had a far better feeling with the new software
If you think about it there's no such thing as irrational user behaviour, there's just a mismatch between your expectations and theirs. The only way to close that is through dialogue. That doesn't necessarily mean going and doing usability studies, often the right dialogue is for them to read the help where the discrepancy is easily dealt with.
The only wrong thing to do is to not listen to what they are saying - or to listen and not really hear them (see the post on here about IE on the Mac - it's the height of arrogance). Of course you are going to get some people who just don't like change and will whinge about anything, but in general if a user will take the time to point out something in your software which bugs them, then you should listen. You may choose to ignore them, but if you listen right you may just as easily uncover a real gem.
I don't believe your users or customers will often innovate for you, but I strongly believe that they are the key to your software being usable, and usability leads directly to success. So to characterise them as irrational probably doesn't serve your best purposes - or theirs. Better to take them seriously to start with and filter out what you consider not to be good feedback.
Developing for a hand held unit many years back, I got contacted by a user who complained that their unit kept on turning off immediately after power on. It turned out to be a bug; the startup message ended with the line "Press any key to continue". It should have said "Press any key, except the big red key marked power, to continue".
One thing I have learned over the years is that time spent with end-users on requirements analysis prior to going anywhere near design is hugely important, as is understanding the culture and educational background of the users. Designing computer systems that look and work like existing manual systems is a good start, as is understanding the workflow. Another hand held van sales delivery system I was involved was specced to look for on-screen customer signatures on delivery, and this was necessary to complete the transaction. It turned out that most of the deliveries actually occurred early morning before anyone was there to sign for them, so the perceived workflow didn't gel with reality at all. The client IT staff didn't actually know this, nor did the business analyst. If you design systems without input from actual end users you do so at your peril.
In my previous job, I was designing a huge trading software for a huge bank.
The software would typically take around 5 minutes to launch.
Of course, the users were complaining a lot about the startup time, especially when the software was crashing during the day, which was happening from time to time.
From the day we added a detailed progress bar (progressing quite regularly, with an indicator of the number of remaining items), the complaints almost stopped.
Typical users would say "I used to take ages to load, but now, it's quite fast"
The next step for us was to display the user interface before the data is loaded instead of after (which makes more sense for an IT point of view)
This time, the modification resulted in a slight performance drop (from 5mn to 5"30), due to the cost of impacting the UI during the loading time.
From a user perspective, the software was much faster this way !!
I was once working on a cms for images. The admin would basically browse though pages of user-made images, and check the ones he wanted to publish. I wrote a nice manual on how the system works, but since everybody knows people don't read manuals, i put some guides on the page telling what to do (in this case, something like: "Check the box for every image you want to publish").
It wasn't long before some guy came pull my sleeve: "There's a bug in your program. It actually tosses the images i don't select, and not the ones i select".
The problem was solved by asking him to read aloud the text on the page.
While novice software designers expect
their users to behave rationally, it's
far from being the case ; I've seen
many times the user perception being
totally disconnected from reality, or
it's feedback obviously irrational.
I think we are the one who should
adapt, not the other way around.
Are you saying we should adapt to irrational behaviour? Software development is already irrational enough (dynamic languages, test driven development, ...), and you expect us to unilaterally bend over backwards to accommodate some distorted expectations?
A few years ago, I designed a small application which was mainly aimed at helping users to input complex data in a database.
Their old method was to input everything into an excel sheet (without validation of any kind), and then to use a vba macro.
My new program added validation, and was able to auto-fill almost half of the data they previously manually entered.
I expected to be a success... which it wasn't ... at all:)
"It's just impossible to use", they said...
I had tested it, asked my mother to test it... my software was fine...
In fact, those users were so used with inputting repetitive data that they used only the keyboard, not the mouse. And of course, I hadn't thought of managing the tab order correctly, so the cursor was just jumping all over the place each and every time they hit "tab", thus the "impossible to use" comment !
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I often work with sales and marketing types that cannot figure out how to use Excel, let alone understand the scope of their requests from a technical perspective. Of course, it would not be fair to expect them to, but that still leaves me with a problem.
What is the best way to show marketing and sales types that they have asked for something that requires a lot of complex programming and some patience?
Could you please share examples of problems and solutions?
Could you please recommend books on this subject?
Thanks!
Break the problem up into as many sub-divided tasks as possible. Provide a per-item estimate in hours beside each one.
When they think of a project as a whole, it seems simple. However, when they see each individual thing that must be done and the number of hours each item will require, it is putting it into terms business people can understand. Suddenly the software solution they want isn't a "black box" to them anymore and they now have some insight into the process.
If you are looking for books I would suggest Software Estimation - Demystifying the Black Art.
The computer will do what you told it to do, not what you want it to do.
Any form of abstractions needed be translated to exact details.
source http://c2.com/cgi/wiki?TeachMeToSmoke
Teacher: "It's hard to express ourselves clearly. You're a smoker, right?
Are you pretty good at it? [Student nods.]
Let's pretend I'm a man from Mars and you are going to teach me to smoke.
Do you have a fresh pack? Let's start with that.
[Takes pack.] OK, now tell me what to do."
Student: "Tear open the pack."
T: [Tears pack to shreds. Cigarettes fly everywhere.]
S: "No, no, tear off the top of the pack!"
T: "OK, sorry, do you have another pack? No? OK, let's just start with this cigarette. [Picks one up.]
S: "Put it in your mouth."
T: [Puts whole cigarette in mouth.]
S: "No, no, just put the end in your mouth!"
T: "Sorry." [Tears filter off, puts whole filter in mouth.]
S: "No, no, don't tear the cigarette, just hold it between your lips!"
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]
... and so on. You can play the game for a long time. It's hard to give clear instructions, even when you know the domain. Programming will endure for a long long time. -- RonJeffries
I had a friend who could do the Rubik's Cube in seconds.
That made me think of this way of explaining to my manager why did our latest project FAIL!
Olivier takes an average of 10 seconds to completely sort all colors of a 3x3 Rubik's Cube after looking at it for approximately 5 seconds.
If you ask him to make an estimate of how long it will take to sort it, you give him the cube, start the clock and after 5 seconds he will say:
"OK, as soon as I start I will be done in 10 seconds"
you smile and say: "Start!"
After 3 seconds you ask him to stop.. give him another Rubik's cube and say.. sort this one instead...
4 seconds after he starts the second Rubik's cube, how long do you think he will take to sort the first one again?
If you answered 7 seconds approximately, congratulations: You're upper management material!
(and Olivier would be rightly entitled to force you to eat the cubes)
I agree with Simucal in the sense that managers tend to do better when you break a problem into hours, rather than into programming tasks. For example, saying to your boss, "That should take about two hours to complete, but I have a few other things that I have to complete first, so I should have it to you by tomorrow." is a lot more useful than saying, "Well, first I have to design an interface to communicate between objects, and then create the classes to implement the interface, and so on." Managers understand what they can see, so anytime you can explain your task in terms of end-user effects, you will likely have more success.
With that said, don't let your manager intimidate you into making promises that you can't keep. You may know that all they want to hear is "I'll have it by the end of the day.", but if you know it can't be done, don't say that it can, hoping that if you have it to them sometime in the next couple days, that it will be "close enough". If you start factoring in time for designing and testing and give them appropriate estimates, eventually they will start to understand how long it takes to accomplish certain types of tasks, and stop expecting everything to be done by yesterday.
I've also noticed that tangible results along the way tend to put their nerves at rest (temporarily, at least). My boss starts demanding finished results when he starts to panic as to whether or not a task will be completed on time. However, when he is able to "see" the step-by-step progression, then he is more likely to understand that we are, in fact, making progress, even though it isn't in the finished product yet.
Also, as you start this process, try to look at things from their point of view, and understand that until you get to a point where you can spend the amount of time you think is necessary, you may have to find a happy medium. There came a point in my experience where I needed to develop a Cache object, and while I would have loved to take several weeks to design and implement a configurable and extensible Cache that could be widely distributed across multiple applications, I had to limit myself to the task at hand. Just make sure that if you decide to scale back or follow through with a short-sighted design, be sure that it is well-documented so you can go back and fix it when you have time (or so another developer can pick up on the train of thought that you were unable to finish). Also, don't sacrifice good coding standards and style, as this will also make your code easier to maintain and update properly in the future.
Good luck!
This one may be a good book for non-programmers to understand some of these issues and pitfalls of runaway requirements:
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
In all seriousness, I think the best thing it to actually tell them that some things are complex and do require complex problem solving, analysis and design. There is a gap between what they do, and what the programmer does and its unfortunate that they will never understand the full implications. You sometimes just have to be firm and explain that it can take alot of time.
Perhaps a breakdown of the task into subtasks and giving them estimates may help.
Make sure you understand their issues too. People will often bring solutions to the table ("we need this feature") rather than start with root business needs. The more you understand the problem the more likely you are to be able to suggest a compromise.
On occassion I've been told a certain large feature is absolutely essential, but I've been able to deploy much simpler solutions that substantially addresses the problem. Sometimes these interim solutions have grown into vital features, just as often I've been able to remove them two releases later without anybody noticing.
In my experience, whenever I started to explain to sales people in the past why a task takes a certain amount of time, they quickly admit that they do not really want to know the technical details, and I am fine with that. I usually do not want them to explain to me why they still have not nailed down that big sale after n days either. To do work effectively, everybody has his own area of responsibility.
Just make sure that your relationship with the sales people that you provide estimates for is good and they trust in your ability to do proper and reasonable estimations and get the work done. IMHO there should be no need to explain and reason an estimation in every detail, but if there is, I would say the real problem lies elsewhere.
And I wholeheartedly agree with "It depends" above.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I find way too many projects to get involved in, way to many languages to play with (and way too many cool features within those languages), and way too many books to read...
How do you guys stay focused and actually get anything done, rather than leaving a trail of partially complete "experiments?"
Seems like there are two types of developers: Tinkerers and Entrepreneurs.
Tinkerers want to know how every little thing works. Once they get the hang of something, they're distracted by everything they don't know. The tech world is brutal for a Tinkerer because there's so much to learn and each new year creates more. Tinkerers are proud of their knowledge.
Entrepreneurs want to know enough to build something really great. They think in terms of features and end-user experiences. You never hear them argue about Python over .NET over Java over C because they just don't care. They're more interested in the result of a language versus the language itself. Entrepreneurs are proud of their user-base.
Sounds like you're struggling with your Tinkerer tendencies. I've got the same problem and have found only one thing that helps - find an Entrepreneur developer that you thoroughly respect. When you put the two together, it's unbeatable. The Tinkerer plumbs the depth of every technical nuance. They keep the Entrepreneur technically honest. In turn, the Entrepreneur creates focus and opportunity for the Tinkerer. When they catch you browsing the Scala site (assuming you're not a Scala developer), they reveal a new challenge in your existing project. Not only that, they're much better at understanding what non-Tinkerers want.
Money, and the feeling of accomplishment that goes along with actually finishing something. When I first thought about working for myself I started coming up with ideas of software that I would develop and then later sell. Of course, I really didn't know if what I was making would actually sell, so it was easy to get distracted and jump at new ideas.
So I decided to go with being a contractor/consultant. When you know that there is a buyer for what you're making, and that somebody is waiting on it, it gives you motivation. If it's an interesting or challenging project, there's a rush associated with finishing it. So that adds extra motivation because you want that rush more and more.
Once I got a fairly steady flow of work-for-hire projects, I found that I can stay focused on my side projects better because I have incentive to practice good time management. I give myself a certain amount of time every day or week to work on my side projects, and it helps me stay focused when I take that time.
Of course, I still go off on tangents occasionally and start new side projects as well, but the ones that I am most interested in I have been able to stick with.
Also, after you finish some projects, then you get a better feel for what it actually takes to go from conception to completion, and it makes it a lot easier to do it again and again.
I think a good programmer may well have lots of unfinished "experiments" hanging around, this is a good thing.
Usually with a good manager, you will be held accountable if your work is simply not getting done. If you're a student, though, it's tougher. I realized that it is impossible to learn everything you want to.
I limit myself to only learning 1 or 2 new languages per year, and only 1 book per month. That seems to be a nice balance between programming chaos and getting my job done well.
Kudos for having a great learning attitude :)
Probably the best motivator (for a team or an individual) is to set goals early and often.
One of the best methods I've observed in project management was the introduction of "feature themed weeks" - where the team (or an individual) was set goals or deliverables which aligned under a general flavour, e.g "Customer Features", "Reporting and Metrics" etc. This kept the team/person focused on one area of delivery/effort. It also made it easy to communicate to the customer where progress was being made.
Also.. Try to make your (or your team's) progress visible. If you can establish an automated build process (or some other mechanism) and "publish" incremental implementation of work over a short period of time you can often gain traction and early by-in which can drive results faster (and help aid in early course correction).
1) I leave a utterly MASIVE trail of unfinished stuff, all side projects of course.
2) When I need motivation to work I open my wallet... That usually does it for me.
I'm building an app I plan on selling and see it as a way of making extra money or reducing the amount of time I spend working for other people.
My wife likes this idea and her encouragement has managed to keep me focused longer than normal as it's now "work" rather than "play"
I find that getting involved with the "business" side of the equation helps tremendously. When you see how much benefit the actual users of your program can get out of your creative solutions to their problems - it's an extreme motivation to provide those solutions to them. :-)