Click here to Skip to main content
Click here to Skip to main content

Time Management Tips for Developers

By , 24 Jul 2012
 

Introduction

Software and web development can be really exciting, after years of work it can reward you a million dollars or you can get in a groove. Many of us only care about keeping a head above water. But isn't it our goal or did we dream about it in school and childhood.

To earn more money, many of us search for additional work and don't bother about anything other than hands down programming. We can't take a rest, we can't spend more time with our family and friends, we can't do anything other than work. This leads to a stress and an unsatisfied life.

But wait. There is a way to make our life better. Really, a few time management principles can do our life successful and improve software and web development to profitable and fascinating levels.

Set your goals: long term and short term

To make life better, first of all you need to know what is "better" for you. Where do you want to be next week, next quarter, next two years, or even next 20 years (if you are young enough Smile. You must decide for yourself what you want from your life.

Do not plan in a lazy way

Napoleon once told that only properly planned things can produce a desired result. Don't ignore this principle and invest time for planning. Remember, mussing is not planning. I like the classical citation: "Sometimes I sit and think and sometimes I just sit". Usually this phenomenon can eat much time. If you find yourself mussing, switch to another work, look out from the window or simply relax your eyes.

Regularly update your plans according to reality.

If you can't plan, just track

If you can't plan anything now, don't worry, you can do it later. Just track whatever you do on a paper, Excel sheet or use a task management software. Update the list every two hours, or at least in the end of the day on in the beginning. This will help you to find common interrupters and recurring tasks, this way you can plan things for future. Even one week of day to day time tracking can bring a light on how we live.

Look at your time journal and try to find out things that don't really need to be done, things that could be done by someone else, work that can be done more effectively or quickly, actions that wastes others' time etc.

You can download a simple time tracking template here.

Collect all tasks in a to do list

Sometimes we have no work, and later we remember (or manager reminds) a number of important tasks, whose are very urgent and important. The only way to avoid such situations is to collect tasks in a to-do list. Add tasks to a list whenever it comes to you from your boss, colleague or from your mind. If you can't access computer, or don't remember the task, write it down on a scratch or any other media. Transfer it to the main list whenever possible.

Estimate every task, set deadlines yourself. This will help you to avoid doing things in a last minute.

Adjust priorities

Drucker Dictum told: "Doing things right is not as important as doing the right things". In software and web development it is possible to spend a lot of time for tasks that produce insufficient value for the customer or even do not produce any value at all. For example, writing a regular expression to split a coma-delimited array or writing a CORBA application to access two methods on a remote server. There is no silver bullet that can shoot all prioritization cases, but a few tips can help:

  1. Ask a customer or manager for the proper task ordering and prioritization first. Be sure to do it beforehand: not every customer can answer immediately.
  2. If someone else is dependent on a specific task then do it first.
  3. For equal tasks set priorities using a task difficulty: ugliest tasks first (some prefer interesting tasks first, why not?).

Delegate when feasible

If someone, who can take a part of your work, is available, do not hesitate to share some work with him. Give objectives, not procedures, take responsibility and accountability. Describe a task clearly. Provide a "how to test" example.

The following rules can be used to determine whether to delegate a specific task or not:

  1. Will he/she do it better or faster than you? If yes, no doubt, delegate it.
  2. Will you commit a task to somebody if you have more important tasks to do? If yes, delegate it.
  3. Is someone is able to complete a work without your assistance, for example if you are out of office? If yes, delegate it.
  4. Of course, you can even delegate your work to your boss, but do not abuse.

In a multi project environment, the work of the whole team cannot be distributed equally to every member. Someone will have to do more and someone less. Using Goldrat's Theory of Constraints, project cannot be completed until the slowest member completes his work. Thus delegation should be promoted inside a team, not only from manager to developer. This process can only be effective in teams with honest and open communication, like in XP and agile teams.

Perfect is not better than good

While writing a code, for example, it is more important to finish in time than to worry about a perfect solution that fits for all. Get the job done and you can add more features later. Do your best and "Get it right the first time". Do not save on coding conventions and code quality. Pure code usually increases support time later. Consider unit tests, it can improve quality and speedup development. Automated tests reward with a confidence.

Split difficult tasks into bite-sized pieces

People usually avoid difficult tasks. Break them down into smaller steps. Complete manageable chunks and soon you will notice that the problem is resolved. A very helpful approach is to add "how to test" notes for each task. This will setup a micro goal and will help in determining task completion. Of course, if these tests can be automated time on repeated tests will be reduced.

Identify your time wasters

Man is a social creature, we deal with people every day and hour. We have colleagues, friends or kin. They can help or slowdown you in various ways. Someone can ask you directly, via phone, instant messaging or email. This leads to interruptions as well as time spending. Interruption of 6 - 9 minutes usually takes additional 4 - 5 minutes to recover. Five interruptions will shoot an hour. It's always good to think about ways to reduce a frequency of such interruptions. It is hard to setup firewall around or ignore others. For example, ignoring phone calls from sposure can lead to unpredictable results ;) The only way to reduce such time spending is to find repeatable time wasters. Once you get the whole picture it is easy to decide where to save and where to spend.

Plan relaxation and recreation

Keith Frayn, professor of human metabolism at Oxford University, told TV Plus: "Any normal person could survive for up to 60 days without food on just a water". But without some sleep men can degrade much quickly. In 1964, a high school student Randy Gardner attempted to break the Guinness Book of World Records for the longest time awake - 260 hours. Stanley Coren describes the day-by-day impact on Randy in the book Sleep Thieves, as documented by John Ross of the US Navy Medical euro-psychiatric Research Unit in San Diego. Randy had trouble focusing his eyes on day 2, hallucinations on day 4, and slurred speech and short attention span by the last day.

Do not expect high productivity if you are tired. Sleep recharges our brains and helps us to think more clearly. Plan your day adequately, do not save on sleeping.

Developers usually sit for 8 hours a day or more in the work place near a computer. This leads to emotional and physical diseases. One of our exposed organs is eyes. Working behind a monitor for a long time, even expensive one, will ruin our eyesight. To reduce pernicious influence on our eyes there are many techniques of eyes training. Type "training eyes" in a search engine and find a suitable training for you. Schedule it daily, just before a dinner, or at any other convenient time.

Do not hesitate to ask friends or colleagues for an advice

Almost every IT project involves risks; they are either hidden or visible in the beginning. Developers have to resolve them. Working on any of them, even a small risk, can take days or even weeks. To avoid these time spending just take the advice or help of your colleague or friend. I have many examples of how this rule reduced a time on difficult tasks and prevented project failures. An example from my experience: customers of our recent project required an extra safety for applications from possible cracks. One part of the protection was to download a component from the server and load this DLL to the application without writing to the disk. Even after two hours of research I couldn't find any useful information. I paused for a moment and tried to recall someone who could help me with it. I asked a friend of mine who has worked as a developer in another company and he helped me. He sent me a link to a tutorial that I was looking for and the problem was resolved.

Reward yourself

Everyone expects a reward or praise for his work, especially completion of something. Lack of a reward can kill our desire to work. This usually leads to a reduced productivity. That is why we prefer working for others than doing something for ourselves. Promise yourself a reward after completing a task or finishing a job. For example, let yourself to watch an interesting movie once you finish developing a page or a new feature or eat some sweets or anything.

Conclusion

This list of time management tips is just a starting point to a new improved life. Following these principles every day can show a way to a successful career, robust health and welfare.

My university teacher always told me that every detail is important. Usualy failture in something happens due a small but important detail that we forgot or skipped. Help yourself to achieve your dreams. Avoid chaotic motion, plan and manage your time, be successful and healthy.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Alexander Fedorenko
Web Developer
Ukraine Ukraine
Member
Alexander Fedorenko is a professional C++ developer since 1996. He completed many custom and shareware projects. One of the successful projects is DevPlanner - tool for personal planning and time management.

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralMy vote of 5memberS. M. Ahasan Habib17 Feb '13 - 2:52 
Nice
GeneralMy vote of 1memberDineshshp27 Jan '13 - 22:34 
aaa
GeneralMy vote of 4memberSastry_kunapuli6 Dec '12 - 3:36 
good tips on better time management,no one ever puts down these thoughts for others
QuestionNice ArticlememberMatt U.16 Nov '12 - 14:06 
I can see how these techniques can improve things greatly. Thanks for the information. I will definitely be trying these out ASAP. I do already mark tasks down as they come. And my new boss recently introduced me to prioritizing tasks to help decide my workflow. Smile | :)
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

GeneralMy vote of 5memberRahul Rajat Singh25 Oct '12 - 18:13 
A very good article.
GeneralMy vote of 4memberDrABELL21 Sep '12 - 7:02 
The article is useful in general, but it requires some clarification and, probably, proofreading as well. As an example, it's kinda hard to extract the meaning of the statement like (quote) "Pure code usually increases support time later" under the the title "Perfect is not better than good". Anyway, kudos to the author for his efforts.
GeneralMy vote of 5memberAndrew Novik6 Aug '12 - 6:34 
Reward yourself - This is interesting thought.
GeneralMy vote of 4membershuang830 Jul '12 - 15:36 
the title "Perfect is not better than good" I think, is not precisely describe what you want to tell us.
GeneralMy vote of 5memberscott.leckie30 Jul '12 - 1:55 
Good article - I'm going to share with my team. Thanks
GeneralMy vote of 1 [modified]memberrizwan muhammed khan gouri25 Jul '12 - 19:51 
good article

modified 22 Jan '13 - 9:18.

GeneralRe: My vote of 1memberscott.leckie30 Jul '12 - 1:54 
Why?
Questionlink not workingmemberronnieaka23 Jul '12 - 19:35 
the time tracking template link isn't working.
error: 502,Bad Gateway
AnswerRe: link not workingmemberAlexander Fedorenko24 Jul '12 - 6:11 
Thanks, I've updated the link.
Regards,
Alexander.

GeneralTypo?memberlukeer19 Jul '12 - 2:56 
In "Perfect is not better than good" you write "[...] conventions and code quality. Pure code will lead to many problems [...]". Could you have been wanting to write "[...] Poor code will lead to many problems [...]"?

Ciao,
 

luker

GeneralRe: Typo?memberAlexander Fedorenko19 Jul '12 - 8:15 
Thanks for your comment. I've corrected it.
Regards,
Alexander,
DevPlanner - Improve Your estimating skills!

GeneralMy vote of 5memberthatraja17 Oct '10 - 21:25 
5 years old but it still effective one. great.
GeneralThanks for sharingmembersanme9819 Jun '06 - 5:04 
Hi Alexander,
 
Thanks for sharing your ideas & tips. It quite useful for every developer.Smile | :)
GeneralNice Jobmembercomputerguru9238225 Feb '06 - 12:19 

These tips are helpful. Thanks for sharing.
 
PJC
QuestionWork Time and Software Companies...memberFarrukh_57 Sep '05 - 21:43 
Hi All,
 
I have always felt my self more focused when i get 6 to 7 hours of night sleep Sleepy | :zzz: ,
and next day working(programming) tasks also went very fine... Smile | :)
BUT this is only true when i get out of the office at good timings of 9am-6pm cos after this long time of programming my head got bang D'Oh! | :doh:
 
My question is ...
If sleep is good for programmers... then why companies try to get their programmers awake more than 12/13 hours of day to sit in the office
 
Where ever i have worked my Bosses always see what time i am spending in office but they donot see what work i have done since the morning...
 

 
Business has new Name, "eBusiness"
GeneralImportant point for all software Engineersmembersura satish7 Sep '05 - 12:49 
Really!! I feel these tips are very Important for all the software engineers. I see most of the developrs do not relax and sometimes even misjudging their productivity. Every days is a lesson for us and we must be in a position to learn and accept the truth's
 
Let us try to follow and improve ourself and keeping ourself happy always ..
 
Satish
GeneralPerfectmemberM_Rizwan6 Sep '05 - 19:20 
Hi Alexander,
 
You have written the most things that i follow.Smile | :) . But your article refreshed the things. I hope in future you would write even a better one. And as far as perfect design and code convensions is concerned. I think if u make ur self use to coding convensions and as soon as you are getting more and more experience. Then you can make the things right at first time( although not 100% exact but close to that). Do we?
 
Best Regards,
 
Rizwan
Generalthanksmemberlallous4 Sep '05 - 21:24 
Hello Alexander,
 
Thanks for the tips and well put article.
 
--
Elias
GeneralYou Forgot! Part IImemberhector santos2 Sep '05 - 9:42 
> Perfect is not better than good"
 
This idea of "near perfect" explains why the industry is so inundated with bugs, security issues, poorly written, hard to read code.
 
I perfer to do the JOB right and not allow "time management" issues lower the quality of a product. I grew up in a corporate environment where the motto is "Getting it right... the first time." It an attitude and QA philosophy.
 
While I can understand the topic is time management, experienced engineers (more than 10 years) and managers understand that not getting it "right the first time," can cost you dearly in time, dollars and customer support problems later on.
 
So it pays to get it right the first time, not later on. Of course, one has to measure what is considered "perfect." "Perfect" means getting the drawn up design specification correct as it was written and expected to work. No 90%, not 95%, but 100%. Anything short of that is a "bug."

 
Hector Santos, CTO
http://www.santronics.com

GeneralRe: You Forgot! Part IImemberSantosh Rao2 Sep '05 - 19:48 
That is obviously right. Everybody must be well aware of costs of fixing it later.
GeneralRe: You Forgot! Part IImemberAlexander Fedorenko3 Sep '05 - 3:17 
Hi,
> No 90%, not 95%, but 100%
These are just numbers. You didn't say anything on how are you measuring it.
 
As we all know, there is no up front design specification what can not be changed later. Thus you can't do 100% right even theoretically. Term “right” is changing in time.
 
Ok, I'm aware about problems you are telling. Poor error-prone code will lead to the project failure. But just telling "No 90%, not 95%, but 100%" is not enough.
 
I'm a fan of Extreme Programming, and I prefer more objective numbers: for example number of running tests or number of written tests per class, or lines of code in a class or a method, etc. This we really can measure and manage.
 
Please distinguish between skipping non required things and writing a poor code.
 
Also you can't tell: "I want to write a perfect code without errors." Errors usually happen not because people wanting to make them. Time management is just a one technique to keep up a good work.

 
Regards,
Alexander.
GeneralRe: You Forgot! Part IImemberhector santos6 Sep '05 - 8:34 
Alexander,
 
To me "100%" is what you expect of out of your design.
 
Of course, "designs" do change and whether that is a result of initial bad design or good old honest "changes" that would be another discussion in vain.
 
Anyway, I think my point was clear. "Getting it right the first time." is not a QA motto I invented. Look it up in Google.
 
In short, it wasn't about failing to reach perfection, but making sure failures and customer related issues are not due because of laziness, sloppiness or "cutting" your time. It is an attitude, a philosophy and unfortunately, in my view, we are lacking a "getting it right the first time" mantra in this every increasing component engineering industry where trust is put more on the 3rd party than in yourself.
 
Thanks
 

 
Hector Santos, CTO
http://www.santronics.com
 
-- modified at 14:54 Tuesday 6th September, 2005
GeneralRe: You Forgot! Part IImemberAlexander Fedorenko6 Sep '05 - 9:16 
You are completely right. "Laziness, sloppiness or "cutting" your time" – are things what time management trying to reduce. Now I'm collecting the information about time management history. This technique seems very old. I'll try to cover it in another article. This is very interesting topic.
 
Regards,
Alexander.
GeneralRe: You Forgot! Part IImemberhector santos6 Sep '05 - 10:33 
Hi,
 
It is old only in the sense it is a long established principle which has somewhat been lost in the last few years. Hence why we have a new breed and generation of people that now believe that "Bugs" and "Failure" is a natural part of the process. In fact, a industry was born on selling you software fixes!! Smile | :)
 
No. I don't believe in the "bugs are ok" mantra and many in the industry are beginning to increasingly be very aware of the negative consequences for such a "Bugs Are Ok, Expected" philosophy.
 
That is not to say "Bugs" don't happen. But you not should be designing with that philosophy. Thats the problem as I see it today. "Ok, we will address/fix that later."
 
Even in XP, there are concerns of not getting it right the first time.
 
http://discuss.joelonsoftware.com/default.asp?joel.3.188719.14
 
Look at Microsoft's Trust Worthy Initiative is about. Bill is finally putting more effort in QA because he is finally starting to feel it.
 
The issue of lowering of quality across the internet is no doubt becoming a growing concern. And its not exclusive to just software, but anything you do.
 
I've been concern about this trend for many years. I saw it immediately with the advent of smarter IDEs and component engineering. Today, the disciplines and designs were merged so you have less reviewers and peers going over your decisions.
 
In the end, it is all a big circle. It all comes back to you and I think we have ALL seen it already one way or another. So this is why, of your entire article, I only pointed out one issue with it which I felt was most critical of being a very significant factor in this industry - not doing your best.
 
I think it is great that you are considering adding this to your next version. I think it is an important concept that needs to be "re-taught" in this fast paced design industry.
 
Sincerely,
 
Hector Santos, CTO
http://www.santronics.com
 

 
-- modified at 16:35 Tuesday 6th September, 2005
GeneralRe: You Forgot! Part IImemberyt3 Sep '05 - 18:11 
Your title CTO gave you away. When was the last time you did the trench works?
 
Yes, it is nice to do it right the first time. A good sound bit that worths no more than the air.
 
Majority of the clients do not have a firm idea about their project. Less about the scope of works.
 
I will do it right the first time if you define it correctly.
 
-- modified at 0:12 Sunday 4th September, 2005
GeneralRe: You Forgot! Part IImemberhector santos6 Sep '05 - 8:08 
As a small company, I wear many hats. CTO is my main title, but I am also the chief software engineer as well. I look at everything to make sure code is designed, developed, reviewed and tested according to specifications. Sure, I'm still old school. I still do Software Walk-thrus and I still use white boards!!
 
But you might have missed the point. "Getting it right...The first time!" is an old corporate engineering/QA philosophy that simply says there is no short cuts. I did not make this motto up; one of the oldest industrial corporations did - Westinghouse Electric.
 
It does not suggest that one should "waste time." Of course not. Only you and your peers can make that decision when measuring your design and/or design changes. If something is questionable, it should be relooked at to make sure there is no question.
 
The point is if you design for a certain outcome, then that is what you should get. If you are 'good' and have foresight to envision issues, then it is your responsibility to bring it up, address it or what have you.
 
Specifically, I believe Alex used a weak example with "naming" example. While I can understand the point, it was too simplistic because the better advice would be to learn and stick to a standard or common practice in naming convention - "Don't waste time picking a name, yet don't bypass a standard style." I still use Hungarian notation for all my variables. So it doesn't matter if its dwMyDog or dwBenji. The key is that its what type it is. Of course, dwBenji may only may make sense to me, dwMyDog would make sense to others code managers.
 
Anyway, overall a very good article. I was just pointing out one aspect that I've had a strong philosophy over my entire long software engineering career (extremely rich). We saw an increase in productivity at the expense of lower quality and security. I do think it is getting better, but I don't think it is a good idea to continue a recommendation of going down the path of least resistance in the name of time.
 
Of course, the smart person will always learn from this and apply the advice accordingly and because I have such a strong faith in the goodwill of people, they will naturally always try to do the "right thing" whether they understand it or not. My point is simple - there is no short cuts to sound product design. Most companies (with rare exceptions) that use the triage and/or cost benefit principle nearly always have problems at some level because of it.
 
In any case, that is a philosophy I have followed for many years. Probably not prudent in the business world. But we don't have a reputation for bad coding too and that helped use to compete with lower support overhead and overall establishing a good reputation with customers for quality.
 
Sincerely,

 
Hector Santos, CTO
http://www.santronics.com

GeneralRe: You Forgot! Part IImemberAlexander Fedorenko6 Sep '05 - 8:54 
Hello Hector,
 
Thank You for the interesting post. I held my breath while reading it. Can You please give me and others an advice on how to "Get it right...The first time"? What techniques do You use?
 
Regards,
Alexander.
GeneralRe: You Forgot! Part IImemberhector santos6 Sep '05 - 9:47 
Hi Alexander,
 
There are many books, articles and thesis on the subject written over many years. Google the term "Getting it right the first time." and get a feel for the philosophy.
 
It is hard to put into words a philosophy I was trained under over many years. I didn't mention this before but to me, it is also an "ethical" principle too. It is simply about doing your best without sacrific. If you feel you are cutting something out or not doing your best for the sake of time or because you don't quite understand something, well, if you feel bad about that, well, that might be a problem. If you don't feel bad about it, then maybe you simply didn't know any better. If you don't care, then we all lose.
 
So it is also about experience too Alexander. Experts can cut time because they know how. When have a question, they are experience enough to research it.
 
There is also common sense too. As a manager, you will assign a complex project or job to an the more experienced engineer simply because he will most likely to get the job done right, the first time over a less experience engineer. Of course, you want the younger person to learn too, so we might spent more time going over their code (Software walkthrus) and provide insights and advice when you can. We ask questions, "why this method over this method?" etc.
 
In keeping with your article, I think maybe adding the point of "Don't waste time over naming, yet do not by-pass standard naming conventions" is probably sufficient as a key consideration to make or add.
 
In regards to the general motto, if you wish to inject this concept int the article (not a bad idea), I would say suggest to discuss it as part of your intro or abstract as a "understood concept" and that your Time Management recomendations should not be construed as a way of bucking the system for writing good solid code.
 
In short, in relationship to your article of "time management" it is important to stress that time can not be sacrificed in achieving the design goals. You might save time upfront, but make the point this saving in time can cost you time and money later if you sacrifice product quality.
 
This philosophy is very effective when you have everyone playing his or her role doing his or her very best without sacrificing the final product.

 
Hector Santos, CTO
http://www.santronics.com

GeneralRe: You Forgot! Part IImemberAlexander Fedorenko6 Sep '05 - 22:26 
Hello Hector,
 
I rewrote topic "Perfect is not better than good". Thanks for interesting tips. This is really important.
 
Regards,
Alexander.
GeneralRe: You Forgot! Part IImemberAlexander Fedorenko30 Jul '12 - 8:54 
Hi Hector, after almost 7 years it's a real pleasure to reread all your comments again. There is so much true and sense in your words.
 
Alexander.
GeneralThanks for the tips...memberVoidPointer1 Sep '05 - 12:33 
Many of them are known and understandable.
 
But many times even though I'm familiar with
most of mentioned principles ,
I just forget or being too lazy to follow them.
 
One thing that I've adopted for now is writing all the "todos" and "tochecks"
to a notebook .. a real one - from paper you know :} .
And not to different pieces of paper that get lost after a day or too.
 
And I think it's prooving itself as a good habbit.
GeneralOf course, you can't delegate your work to your boss.memberthudriact1 Sep '05 - 6:48 
Well, sometime you can if:
- Your boss is smart enough (some are Poke tongue | ;-P )
- There are too many unplanned things that popup and you are the only one which can do them Cry | :((
- Nobody else is available for doing your regular job while you do that...
 
Anyway, the second point is most of the time caused by a bad planning from your boss, so it is normal he helps you to fix his mistakes.
 
The main problem is that it makes your boss doing your easy tasks, and so you only do the exhausting ones... It is nice sometime to just do "stupid easy things" like painting a bitmap button, especialy when you just passed the last 2 weeks burning your brain on a very complex algorithm.
 
So, do not abuse this solution, but I agree that once in a while, this may be... priceless Laugh | :laugh:
GeneralThe "con" jobmemberfwsouthern1 Sep '05 - 16:08 
Of course you can -- its called a "con" job -- just compliment his skills and intuitive abilities and praise him for his sage advice -- after all, the dumb bastard needs to work for his pay also, doesn't he? (Unless, of course, if you are the boss .....)
GeneralRe: The "con" jobmemberAlexander Fedorenko1 Sep '05 - 21:55 
I forgot what I'm very happy when I can delegate assigned tasks back to my boss: "This is not my job, this is your job". But it seems what this was not make him happy Laugh | :laugh:
 
Thanks for the correction. I've changed this in the article.

 
Regards,
Alexander.
GeneralYou forgot:memberFrans Bouma1 Sep '05 - 4:38 
close Email, browser, RSS reader and IM client when doing serious work. Only then you'll be able to full concentrate and run a less risk of getting distracted by an email / new items on an rss feed or someone who wants to chat over IM.
 
It also helps keeping focussed on what you're doing, for example when it's boring.
 
--
Only the true wise understand the difference between knowledge and wisdom.
GeneralRe: You forgot:memberAlexander Fedorenko1 Sep '05 - 5:00 
I completely agree with You. This is really helpful. But sometime people can reach You via NET SEND Wink | ;)
 
Regards,
Alexander.
GeneralRe: You forgot:memberAlexander Fedorenko1 Sep '05 - 5:04 
This is a case for the next article, on how developer can manage emotions and stress.
 
Regards,
Alexander.
-- modified at 11:04 Thursday 1st September, 2005
GeneralRe: You forgot:memberDario Solera1 Sep '05 - 6:08 

Please note that you can disable the Messenger Windows service... Laugh | :laugh:
 


[ITA] Tozzi ha ragione: Gaia si sta liberando di noi.
[ENG] Tozzi is right: Gaia is obliterating us.
GeneralRe: You forgot:memberAshley van Gerven1 Sep '05 - 13:47 
If you do leave email open you can always switch off distracting notifications.
 
Interesting article: http://www.w-uh.com/articles/030308-tyranny_of_email.html[^]
GeneralRe: You forgot:memberD4Skunk2 Sep '05 - 0:46 
Another one : avoid sites like this if not necessary (Or for Frans, like GOT bijvoorbeeld Wink | ;) )
Mental note to self : remove quake3 from all my pc's
 
Tom
 
Core
GeneralRe: You forgot:memberComputerGuyCJ2 Sep '05 - 5:21 
LOL. These threads can sometimes provide some much needed entertainment though - good for reading during breaks

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web03 | 2.6.130523.1 | Last Updated 24 Jul 2012
Article Copyright 2005 by Alexander Fedorenko
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid