Remove as many distractions as possible to focus on tasks. Turn off email, turn off IM, etc... even if for a set period of time and then during a break check them.
Take time to learn about other coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget. I know this one really sounds counter productive but it really isn't. Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
Take breaks and be aware of your body. When we are tired we don't think as well and will make more mistakes, become frustrated more easily, etc...
Learn to use the 80 / 20 rule to your advantage. I don't mean skimp or be lazy. Often though we will work our tail off for that 20% when it wasn't necessary.
Set goals for yourself (daily, weekly, bi-weekly). Make sure the goals are also in line with those you are coding for or you may find you have wasted some time.
From a technical aspect consider:
Consider Unit testing / TDD. I have found in my own work that this actually saves time. It takes a while to get the hang of but with anything you will get better.
Care for your code. Refactor it (especially if you start unit testing). The better your code is the easier it is to maintain which takes less time. The easier it is to understand the faster you can change / implement features.
I'm learning to spend a lot more time planning out my day than I used to. This includes planning out projects, down to writing psuedo-code for the programming I need to do. I find that with all the interruptions in my schedule, it's difficult for me to get started at something. Having everything broken down into small tasks makes it much easier to start after an interruption.
A corrolary of Conway's Law is that you need to test the internal software interfaces which separate/integrate developers, whereas a "one man army" don't need to explicitly test his internal interfaces in this way.
A lot of the other tips are good but they equally apply to developers working in a team as well as a lone developer.
I think the hardest thing as a one man team is effective communication with the rest of your company. You will always be a lone programmers voice in any meeting or discussion around how best to build software.
As a result I'd advise trying to improve negotiation skills and focus on improving the way you describe technical concepts in terms a non-programmer can understand. Reading books such as Getting to Yes and How to win friends and influence people are a good way to start.
When there is more than one person agreeing on a viewpoint, the viewpoint automatically gains credibility with those you are trying to convince. In the absence of this possiblity you need to work extra hard at preparing your arguments with well-researched evidence and a balanced view.
I'm in the same situation. There's already a lot of good advice above but one thing I'd add is find when your best coding times are and make sure you're coding during that time. I have a few hours in the morning that I seem to be at my best for coding. I try to keep that time free of all distractions. Plan things like meetings, writing documentation, testing (at least the tedious, repetitive stuff), and all that other stuff for your less productive time. Keep those coding hours when you're 2 to 5 times more productive for coding.
Make sure you refactor early and often. That serves almost like a second set of eyes (for me, at least).
Don't work insane hours (especially tricky if you're working from home). Actually, working less hours often proves more productive as the impending break/end of day pressure increases your efficiency.
You may want to look up Parkinson's Law for work/time management.
I use a text file to collect all the things I do every day. Every time I run into a problem or have a question or find a solution, I add it to my file. It's very low-tech but it provides a wealth of information, like "where am I spending most of my time?" or "how did I fix that problem before?". Also makes it super-quick to give your client a list of hours at the end of your billing cycle.
I also use another text file (per client) that contains all the work items on my plate, arranged in order of priority, and updated frequently. It helps both me and my clients focus on what I should be working on next, so the pump is always primed.
Eventually I'll move away from flat text files to using something like FogBugz, but for now I can't beat the price, or how easy it is to search, or how easy it is to e-mail.
发布评论
评论（8）
我要做的事情的每日清单。
尽可能消除干扰，专注于任务。关
电子邮件、关闭即时通讯等...即使
一段设定的时间，然后
在休息期间检查它们。
花时间学习其他编码技术、工具和编程智慧。我发现这对我的发展至关重要。只需编写代码并感到高效，这非常容易。如果你有更多的知识/武器来敲击下一个小部件，会怎么样呢？我知道这听起来确实适得其反，但事实并非如此。知识/诀窍是我们真正的货币。我们了解得越多，就越能更好地决定如何完成某件事并做得更快。
休息一下并注意自己的情况
身体。当我们累的时候，我们不会
也思考并会做出更多
犯错误，变得更加沮丧
轻松地等等...
学习如何使用 80 / 20 规则来解决你的问题
优势。我并不是说吝啬或吝啬
懒惰的。尽管我们常常会努力工作
减少那 20%，而事实并非如此
必要的。
为自己设定目标（每日、
每周一次、每两周一次）。确保
目标也与你的目标一致
正在编码或者您可能会找到您
浪费了一些时间。
从技术方面考虑：
这实际上节省了我自己的工作
时间。需要一段时间才能获得
掌握但随心所欲
变得更好。
（特别是如果你启动单位
测试）。你的代码越好
越容易维护
需要更少的时间。越容易
了解改变的速度越快
/ 实现功能。
Daily list of what I am going to do.
Remove as many distractions as possible to focus on tasks. Turn off
email, turn off IM, etc... even if
for a set period of time and then
during a break check them.
Take time to learn about other coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget. I know this one really sounds counter productive but it really isn't. Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
Take breaks and be aware of your
body. When we are tired we don't
think as well and will make more
mistakes, become frustrated more
easily, etc...
Learn to use the 80 / 20 rule to your
advantage. I don't mean skimp or be
lazy. Often though we will work our
tail off for that 20% when it wasn't
necessary.
Set goals for yourself (daily,
weekly, bi-weekly). Make sure the
goals are also in line with those you
are coding for or you may find you
have wasted some time.
From a technical aspect consider:
my own work that this actually saves
time. It takes a while to get the
hang of but with anything you will
get better.
(especially if you start unit
testing). The better your code is
the easier it is to maintain which
takes less time. The easier it is to
understand the faster you can change
/ implement features.
我正在学习比以前花更多的时间来计划我的一天。这包括规划项目，直至为我需要执行的编程编写伪代码。我发现由于我的日程安排被打断，我很难开始做某件事。将所有事情分解为小任务可以让中断后更容易开始。
I'm learning to spend a lot more time planning out my day than I used to. This includes planning out projects, down to writing psuedo-code for the programming I need to do. I find that with all the interruptions in my schedule, it's difficult for me to get started at something. Having everything broken down into small tasks makes it much easier to start after an interruption.
根据运筹学，最短的工作优先是完成最多事情的最佳调度程序。
According to operational research, shortest job first is the best scheduler to get most amount of things done.
我编写并运行集成和系统测试，但没有单元测试，因为我不需要早期（预集成）测试：应该进行测试内部实现，还是只测试公共行为？
康威定律的一个推论是，您需要测试分离/集成开发人员的内部软件接口，而“一人军队”不需要明确测试他的内部接口都是这样的。
I write and run integration and system tests, but no unit tests, because I've no need for early (pre-integration) testing: Should one test internal implementation, or only test public behaviour?
A corrolary of Conway's Law is that you need to test the internal software interfaces which separate/integrate developers, whereas a "one man army" don't need to explicitly test his internal interfaces in this way.
许多其他技巧都很好，但它们同样适用于团队中工作的开发人员以及单独的开发人员。
我认为作为一个人的团队，最困难的事情是与公司其他成员进行有效的沟通。在任何有关如何最好地构建软件的会议或讨论中，您将永远是一个孤独的程序员。
因此，我建议尝试提高谈判技巧，并重点改进以非程序员可以理解的方式描述技术概念的方式。阅读诸如 Getting to Yes 和 如何赢得朋友并影响人们是一个很好的开始。
当不止一个人同意某一观点时，该观点就会自动获得你试图说服的人的信任。如果没有这种可能性，你需要加倍努力，用经过充分研究的证据和平衡的观点来准备你的论点。
A lot of the other tips are good but they equally apply to developers working in a team as well as a lone developer.
I think the hardest thing as a one man team is effective communication with the rest of your company. You will always be a lone programmers voice in any meeting or discussion around how best to build software.
As a result I'd advise trying to improve negotiation skills and focus on improving the way you describe technical concepts in terms a non-programmer can understand. Reading books such as Getting to Yes and How to win friends and influence people are a good way to start.
When there is more than one person agreeing on a viewpoint, the viewpoint automatically gains credibility with those you are trying to convince. In the absence of this possiblity you need to work extra hard at preparing your arguments with well-researched evidence and a balanced view.
我也有同样的情况。上面已经有很多好的建议，但我要补充的一件事是找到最佳编码时间，并确保您在该时间进行编码。我早上有几个小时的时间似乎处于最佳的编码状态。我尽量让这段时间不受任何干扰。计划会议、编写文档、测试（至少是乏味、重复的事情）以及所有其他事情，以节省您生产力较低的时间。当您的编码效率提高 2 到 5 倍时，请保留这些编码时间。
I'm in the same situation. There's already a lot of good advice above but one thing I'd add is find when your best coding times are and make sure you're coding during that time. I have a few hours in the morning that I seem to be at my best for coding. I try to keep that time free of all distractions. Plan things like meetings, writing documentation, testing (at least the tedious, repetitive stuff), and all that other stuff for your less productive time. Keep those coding hours when you're 2 to 5 times more productive for coding.
我使用文本文件来收集我每天所做的所有事情。每当我遇到问题或有疑问或找到解决方案时，我都会将其添加到我的文件中。它的技术含量很低，但提供了大量信息，例如“我大部分时间都花在哪里？”或“我之前是如何解决这个问题的？”。还可以超快速地在计费周期结束时向您的客户提供小时列表。
我还使用另一个文本文件（每个客户），其中包含我盘子上的所有工作项目，按优先级顺序排列，并经常更新。它可以帮助我和我的客户专注于我接下来应该做的事情，因此泵始终处于启动状态。
最终，我将不再使用纯文本文件，而是使用 FogBugz 之类的文件，但目前我无法超越价格、搜索的便捷性或发送电子邮件的便捷性。
I use a text file to collect all the things I do every day. Every time I run into a problem or have a question or find a solution, I add it to my file. It's very low-tech but it provides a wealth of information, like "where am I spending most of my time?" or "how did I fix that problem before?". Also makes it super-quick to give your client a list of hours at the end of your billing cycle.
I also use another text file (per client) that contains all the work items on my plate, arranged in order of priority, and updated frequently. It helps both me and my clients focus on what I should be working on next, so the pump is always primed.
Eventually I'll move away from flat text files to using something like FogBugz, but for now I can't beat the price, or how easy it is to search, or how easy it is to e-mail.