Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What are some tips for helping to design and construct applications faster?

share|improve this question

closed as not constructive by gnat, Jarrod Roberson, Walter, Yannis Rizos Jun 20 '12 at 3:46

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.If this question can be reworded to fit the rules in the help center, please edit the question.

42  
What slows you down now? –  user1249 Nov 2 '10 at 16:45
4  
I think a better way of looking at it is not how to work faster but how to reduce the amount of time it takes. –  gablin Nov 2 '10 at 22:24
4  
Speed, features, quality. Choose one. –  Kramii Nov 3 '10 at 10:04
3  
I would probably be faster if I did not wasted time on StackExchange. –  Keyo Nov 3 '10 at 22:52

27 Answers 27

up vote 114 down vote accepted

Understand that doing it right the first time, no matter how long it takes, is almost always going to be faster and cheaper than having to go back and fix it, or do it all over again.

share|improve this answer
33  
-1 - I ALWAYS do it wrong the first time (e.g. simplify and hard-code things that should be dynamic). Doing it right the first time is usually just impossible. Doing it wrong gives you a sense of how to do it well.. At least on the second time. –  Oren A Nov 2 '10 at 21:08
3  
@John - writing code which ends up with an explosion is not the right way to do it. –  Seth Nov 2 '10 at 23:02
3  
@Oren: the point is not to do it perfectly the first time but good enough (ie pretty well) so you don't have to come back to fix and redo everything. There will always be some change you did not anticipate but by having a good design you will save lots of time. I think that's what John meant and that's pretty much what I think too. By having a good design, change and bug fixes will be a walk in the park vs having no design (stuff just hacked up). (btw I don't mean necessary formal design, just structured code if you will (but formal design of course helps)). –  n1ckp Nov 2 '10 at 23:03
7  
This is phrased poorly--Much of the theory behind XP is that it's better to get it running on the computer in some form then re-write it 3 times instead of getting stuck designing it (IMO this works on some problems, not all). The big savings aren't getting it right the first time, but getting it right before it leaves for QA and before it gets to the customer, but internally evolutions are fine if that's how you work. –  Bill K Nov 2 '10 at 23:49
3  
@Bill K, to paraphrase Tony Stark, I respectfully disagree. My experience has been that most people CAN get it right, the first time, if you give them the training, tools, support, and, most importantly, the TIME to get it right. If your experience is that the vast majority of coders are incompetent, not to be trusted with even a BASIC interpreter, then perhaps you should take a long, hard look at your recruiting and/or job-hunting practices, and discover why you are continually working with the crud at the bottom of the barrel, instead of the cream at the top. –  John R. Strohm Nov 9 '10 at 13:01

Focus. That's the key to working fast. I use the Pomodoro Technique to help me focus in short but intense intervals.

The technique uses a timer to break down periods of work into 25-minute intervals called 'Pomodori' (from the Italian word for 'tomatoes') separated by short breaks. Closely related to concepts such as timeboxing and iterative and incremental development used in software design, the method has been adopted in pair programming contexts. The method is based on the idea that frequent breaks can improve mental agility..

share|improve this answer

Don't think of speed as a goal, but as a side-effect. This is something I got out of racing, not anything computer related. When you're a smooth driver, speed just happens. Same in coding; optimize your code for correctness, sticking to principles, and general 'sucklessness.' Hacks, idioms, and witticisms might seem sexy over beer when talking with your code-brethren, but in the long run it will bite you in the ass. "I don't have time for shortcuts" is an easy way to remember it.

share|improve this answer

One of the biggest time sinks is tracking down bugs.

I find that this can be greatly reduced by using asserts liberally throughout the codebase. This makes sure that, if your code has a bug, it fails fast, with a good diagnostic error message, and close to the root of the problem. Asserts are not a substitute for unit tests, but IMHO if you're going to focus your energy on one or the other, asserts are more important because:

  1. Some things are inherently hard to come up with a good test case for.
  2. Unless your unit tests are ridiculously fine grained, asserts often narrow down the root cause of a bug more than failing unit tests do.
  3. Unit tests only test the specific test cases that you thought of. Asserts are more general sanity checks that will see real-world inputs.
  4. You can write asserts as you go. Unit tests need to to be written as a separate step.
share|improve this answer
1  
Wow! This is really useful. Is there some way to remove them all once code is ready for production? –  sixtyfootersdude Nov 2 '10 at 20:50
3  
That's kind of the point of asserts. All you have to do is hit a compiler switch and they're gone. –  dsimcha Nov 2 '10 at 20:52
3  
There is a very old idea, that remains relevant, even today. You started with a blank sheet of paper (or a blank screen). There were no bugs on that blank sheet (or screen). The only way bugs get on there is if YOU PUT THEM THERE. So, if you were to stop, and think, and NOT WRITE THE BUG IN THE FIRST PLACE, there wouldn't BE any bugs. Of course, that would require you to take the time to do it right the first time, wouldn't it... –  John R. Strohm Nov 6 '10 at 22:45
1  
@sixtyfootersdude: but do you really want to remove the tests for production ? In C++ I transform the abort() call (debug) to an exception being thrown with an image of the stack (release). Sure it slows down the program a bit, but better that than having an inconsistent state. –  Matthieu M. Jan 23 '11 at 13:28

Paper and pencil. Think it through in the head before typing it.

share|improve this answer
2  
+1 for the 'thinking it through' before hand, but the 'pencil & paper' could be whatever tool works for you. –  John MacIntyre Nov 2 '10 at 16:59
21  
Not programming-specific but one of my favorites: "You can use an eraser on the drafting table or a sledge hammer on the construction site." — Frank Lloyd Wright –  Philip Regan Nov 2 '10 at 17:31
1  
@John MacIntyre: of course it could be any tool but I think you should give a try to pen and paper. It really is not the same for me than writing on a computer for jotting ideas down (computer is better for more formal text though, in my experience, as it is faster). If you meant whiteboard, yes that's should be comparable but is more when you communicate to a team vs just write some quick notes down when developping. –  n1ckp Nov 2 '10 at 23:09
1  
@n1ck: You really should try the whiteboard, even just when doing notes for yourself. Beeing able to get a distance to the note your write and beeing able to walk around while looking at / thinking about your notes, really helps a lot. Try it. :) –  Bjarke Freund-Hansen Nov 3 '10 at 7:24

Eliminate Muda.

Muda (無駄) is a traditional Japanese term for an activity that is wasteful and doesn't add value or is unproductive

All these things like "Learn more maths/logic, read more technical books, increase your typing speed, ..." are not so important as they looks. Everyone is specific with his own strengths and weaknesses. If you rise your typing rate, this does not mean that you will work faster while you still spend 1.5 hour to deploy system on a server. This is totally related with DRY (don't repeat yourself) philosophy. Look at your working habits, find out what are you doing repeatedly and what you could optimize.

Write scripts to automate these tasks (deploy/migrate/init projects, convert some data, etc.), create templates you working on. Use universal tools so you can master them more. For example I'm using VIM to write code, specifications (using reStructured text and then convert it to PDF's/HTML), mails and all other text related stuff. I'm learning VIM and I could use my just increased skills to all these tasks (coding, writing).

By optimizing all these mudas you can save a lot of time and increase your performance. It is better to waste few hours more at the 1st time to automate task and all other times solve it only by running some script.

share|improve this answer

The things that you're bad at tend to be the things that you're slow at. They also tend to be the things that you enjoy the least. Some amount of this relationship is causal in both directions (if you don't enjoy it, you procrastinate to avoid doing it - and if it's more time-consuming than rewarding, of course doing it is going to be a painful process).

You can take advantage of this correlation by reframing your question. Make sure that you're asking yourself, on a regular basis, what is my biggest pain point and how can I remove it? Looking at your work (or hobbies, or whatever) in this light will very quickly show you which tools you need to find or get better with, which processes you need to automate or at least take really good notes on, and which organizational factors you need to address. If you dread regression testing your changes, write some automated tests. If looking up the methods you need is a pain, go get an IDE with decent autocompletion. If everything you do is a never-ending cascade of misery, update your resume. :-)

share|improve this answer

For a programmer, decent knowledge of a scripting language such as Python to quickly prototype their ideas and discussing the prototype with others is invaluable. The closer the prototype is to the actual requirement, the lesser time spent talking and more with coding, documenting, testing and supporting and maintaining/upgrading. The actual coding becomes a simple translation from the script to the programming language.

And, knowledge of sed, awk, vim, emacs(preferably elisp as well), shell scripting, and a decent knowledge of all the tools available on the OS with the knowledge of when to use the tools could help losing time as well.

share|improve this answer

You should be able to type as fast as you can think. Maybe faster.

If there is a lag between the time you think and the time you can get code onto your editor, then you have a problem. If you have to think about the keys you are typing when you are typing, you have a bigger problem.

share|improve this answer
3  
I'm not sure this (taken literally) is reasonable. I think faster than a professional typist can type. But I have yet to meet a dev who types slower than 70 wpm once they get going. –  Ethel Evans Dec 17 '10 at 20:57

Get a working version as soon as possible! (Prototyping)
Then make it better. (Refactoring)

share|improve this answer

Look for ways to automate certain tasks. Create little widgets that do the grunt work for you.

For Example: Here is a SQL stored procedure I wrote that produces the SQL code for updating a database table. Granted the output it's not perfect and requires a little tweaking but it does do 90% of the grunt work. Enjoy.

CREATE PROCEDURE [dbo].[zzzGenerateUpdateProc] 

@TableName  varchar(255)

AS

SET NOCOUNT ON

-----------------------------------------------------------------------
-- 
-----------------------------------------------------------------------
DECLARE @Today varchar(10)
DECLARE @YYYY varchar(4)
DECLARE @NumColumns int
DECLARE @i int
DECLARE @Data varchar(250)
DECLARE @PrimaryKey varchar(100)
DECLARE @PrimaryKeyVariable varchar(100)
DECLARE @DataType varchar(20)
DECLARE @ColumnName varchar(50)
DECLARE @ColumnLength varchar(20)
DECLARE @MaxLenColumnName int

SET @Today = CONVERT(varchar(10),GETDATE(),101)
SET @YYYY = CAST(DATEPART(yy,GETDATE()) AS varchar)

CREATE TABLE #SourceCode
(
    LineNum int identity(1,1),
    ASPCode varchar(255)
)

CREATE TABLE #TempSchema
(
    Id           int identity(1,1),
    TableName    varchar(50),
    Prefix       varchar(3),
    ColumnName   varchar(50),
    DataType     varchar(50),
    ColumnLength varchar(20)
)


GOTO GetSchema
GetSchema_Return:


Insert Into #SourceCode (ASPCode) VALUES('CREATE PROCEDURE [dbo].[spUpdate[ChangeThis]] ')
Insert Into #SourceCode (ASPCode) VALUES('')
SET @i = 0
WHILE @i < @NumColumns
BEGIN
  SET @i = @i + 1
  SET @DataType = (SELECT DataType FROM #TempSchema WHERE Id = @i)
  SET @ColumnName = (SELECT ColumnName FROM #TempSchema WHERE Id = @i)
  SET @ColumnLength = (SELECT ColumnLength FROM #TempSchema WHERE Id = @i)

  SET @Data = 
    CASE LOWER(@DataType)
        WHEN 'bigint'            THEN '@' + @ColumnName +' bigint'           
        WHEN 'binary'            THEN '@' + @ColumnName + ' binary'           
        WHEN 'bit'               THEN '@' + @ColumnName + ' bit'              
        WHEN 'char'              THEN '@' + @ColumnName + ' char' + @ColumnLength            
        WHEN 'datetime'          THEN '@' + @ColumnName + ' datetime'         
        WHEN 'decimal'           THEN '@' + @ColumnName + ' decimal(14,4)'          
        WHEN 'float'             THEN '@' + @ColumnName + ' float(14,4)'            
        WHEN 'image'             THEN '@' + @ColumnName + ' image'            
        WHEN 'int'               THEN '@' + @ColumnName + ' int'              
        WHEN 'money'             THEN '@' + @ColumnName + ' money'            
        WHEN 'nchar'             THEN '@' + @ColumnName + ' nchar' + @ColumnLength
        WHEN 'ntext'             THEN '@' + @ColumnName + ' ntext'            
        WHEN 'numeric'           THEN '@' + @ColumnName + ' numeric(14,4)'           
        WHEN 'nvarchar'          THEN '@' + @ColumnName + ' nvarchar' + @ColumnLength          
        WHEN 'real'              THEN '@' + @ColumnName + ' real(14,4)'             
        WHEN 'smalldatetime'     THEN '@' + @ColumnName + ' smalldatetime'    
        WHEN 'smallint'          THEN '@' + @ColumnName + ' smallint'         
        WHEN 'smallmoney'        THEN '@' + @ColumnName + ' smallmoney'       
        WHEN 'sql_variant'       THEN '@' + @ColumnName + ' sql_variant'      
        WHEN 'text'              THEN '@' + @ColumnName + ' text'             
        WHEN 'timestamp'         THEN '@' + @ColumnName + ' timestamp'        
        WHEN 'tinyint'           THEN '@' + @ColumnName + ' tinyint'          
        WHEN 'uniqueidentifier'  THEN '@' + @ColumnName + ' uniqueidentifier' 
        WHEN 'varbinary'         THEN '@' + @ColumnName + ' varbinary' + @ColumnLength       
        WHEN 'varchar'           THEN '@' + @ColumnName + ' varchar' + @ColumnLength          
        ELSE '@' + @ColumnName + 'unknown'
    END
    IF @i < @NumColumns SET @Data = @Data + ','
  INSERT INTO #SourceCode VALUES (@Data)
END
Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('AS')
Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('SET NOCOUNT ON')
Insert Into #SourceCode (ASPCode) VALUES('')

SET @ColumnName = (SELECT ColumnName FROM #TempSchema WHERE Id = 1)

Insert Into #SourceCode (ASPCode) VALUES('IF @'+ @ColumnName + ' = 0 GOTO InsertRecord')
Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('-----------------------------------------------------------------------')
Insert Into #SourceCode (ASPCode) VALUES('UpdateDatabase:')
Insert Into #SourceCode (ASPCode) VALUES('-----------------------------------------------------------------------')
Insert Into #SourceCode (ASPCode) VALUES('UPDATE ' + @TableName + ' SET')

SET @i = 1
WHILE @i < @NumColumns
BEGIN
  SET @i = @i + 1
  SET @ColumnName = (SELECT ColumnName FROM #TempSchema WHERE Id = @i)
  SET @Data = @ColumnName + ' = @' + @ColumnName 
    IF @i < @NumColumns SET @Data = @Data + ','
  INSERT INTO #SourceCode VALUES (@Data)
END

SET @ColumnName = (SELECT ColumnName FROM #TempSchema WHERE Id = 1)
Insert Into #SourceCode (ASPCode) VALUES('WHERE ' + @ColumnName + ' = @' + @ColumnName)
Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('RETURN 0')
Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('-----------------------------------------------------------------------')
Insert Into #SourceCode (ASPCode) VALUES('InsertRecord:')
Insert Into #SourceCode (ASPCode) VALUES('-----------------------------------------------------------------------')
Insert Into #SourceCode (ASPCode) VALUES('INSERT INTO ' + @TableName)
Insert Into #SourceCode (ASPCode) VALUES('(')


SET @i = 1
WHILE @i < @NumColumns
BEGIN
  SET @i = @i + 1
  SET @ColumnName = (SELECT ColumnName FROM #TempSchema WHERE Id = @i)
  SET @Data = @ColumnName
    IF @i < @NumColumns SET @Data = @Data + ','
  INSERT INTO #SourceCode VALUES (@Data)
END
Insert Into #SourceCode (ASPCode) VALUES(')')
Insert Into #SourceCode (ASPCode) VALUES('VALUES')
Insert Into #SourceCode (ASPCode) VALUES('(')

SET @i = 1
WHILE @i < @NumColumns
BEGIN
  SET @i = @i + 1
  SET @ColumnName = (SELECT ColumnName FROM #TempSchema WHERE Id = @i)
  SET @Data = '@' + @ColumnName
    IF @i < @NumColumns SET @Data = @Data + ','
  INSERT INTO #SourceCode VALUES (@Data)
END

Insert Into #SourceCode (ASPCode) VALUES(')')


Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('RETURN 0')
Insert Into #SourceCode (ASPCode) VALUES('')
Insert Into #SourceCode (ASPCode) VALUES('SET NOCOUNT OFF')

SELECT ASPCode FROM #SourceCode

DROP TABLE #TempSchema
DROP TABLE #SourceCode



RETURN 0

SET NOCOUNT OFF
share|improve this answer

Automate.

Take manual processes and automate them as much as possible. The time you take to automate will help you better understand the task at hand and help avoid human errors.

share|improve this answer

When a business analyst, QA person, other interested party comes over to your desk and says, "Hey, I had a question about..." or "Could we discuss blah...".

Be sure to respond with, "I'm just wrapping something up, could I come see you in an hour?"

Be polite, and follow up with them when you said you would. You wouldn't believe how establishing boundaries and keeping people from waltzing into your office and yammering about whatever they feel like improves your productivity.

share|improve this answer
4  
And it's amazing how much it harms their productivity and thus the whole project. –  HLGEM Dec 6 '10 at 19:40

Write a lot of code in your spare time. Just throwaway projects, if you like. Little apps. Pay attention to what works, and what holds you back. Look for better ways of doing the things that hold you back the most.

Write the code rapidly for one project and without too much consideration for design. Notice what works about this, and what doesn't. Start another project, and use more up-front planning, design patterns and abstractions. Code as slowly and elegantly. As you can notice what works about this approach, and what doesn't.

Repeat all this dozens and hundreds of times. At the end, you will have learned a bit.

Oh yeah and read the source code to (good) open source projects. :-)

share|improve this answer

I often think about how to optimize how I work. I have tried a lot of things and here are things that I have found to work:

  • Multiple screens so that I can see more things at once. Note that this does not include things like email or IM. This is so that I can have more code up and see more test machines at once. I try to keep it to that are needed at the same time. Also I have found that having a log up in one window and code in another is better than switch between the two. It seems to stress my memory less.

  • Having a better/more complete understanding of the system that I am working with. This allows me to make better decisions and make them faster.

  • Test Driven Design(TDD). This has allowed me to more fully and more easily test my code so that I know how it will perform in most if not all scenarios. My methodology here is to test the system closer to the code that has been changed.

  • A working debugger. I don't have this now but in the past it has greatly improved development speed.

  • Excellent logging facility. This takes the place of a debugger most days.

  • Visualization tools. This allows me to get the picture of how a lot of things work together all at one time.

  • Minimal distractions. I know this is hard because of the constant interruptions but really this is more about limiting things like the internet and email access.

share|improve this answer
2  
No there used to be one but it broken and no one seems to want to spend the time to get it up and running. My previous job was working on an electro-mechanical system where we had a debugger but because of all the moving parts you could not really set breakpoints or step through code. From that experience I learned a lot of debugging techniques that did not involve a debugger. –  barrem23 Nov 8 '10 at 4:19

Use design patterns, develop your own, don't reinvent yourself.

Sketch wireframes for "testing" user interface and interaction BEFORE writing any code, review them with your users.

Manage change and requirements.

Refactor and reuse as much code as possible, buy ready made components, develop your own "high level" libraries to write even less code.

share|improve this answer

Say NO! This is vital to keeping crap from interrupting you or throwing you off what you should really be doing.

share|improve this answer
8  
Evolve from a place where you have no power into a place where you have "No!" power :) –  Kaz Dragon Nov 3 '10 at 10:44

Have someone in authority manage requests. The easiest features are the ones you don't add.

There also needs to be a technical referee. At some point you have to stop all the debates and make an informed decision.

Teams developing consistent code allows a more flexible approach when having to go back and fix someone else's code. It is important to take personal pride and ownership in your own work, but your code ultimately belongs to your benefactor.

share|improve this answer

My biggest thing has been accepting that it's OK to do the right thing and not rush it.

I find that when I look at a problem, I see an easy "Hacky" way and then in the back of my mind there is the concept that "There is a better way".

I've never saved time with the hacky way and these days I don't even go down that road. Doing it fast is just going to cost you or someone else extra work down the line, almost always before your first release, this means that it doesn't even save you time in the short run!

Sometimes the "Right thing" might just be refactoring to split a class that seems to be addressing multiple concerns, and sometimes it might be something massive like moving a bunch of data out of your code and into arrays or config files.

share|improve this answer
  1. Ask questions. The more angles you understand the problem from, the better you're equipped to solve it.
  2. Propose alternatives. If a large portion of the complexity is coming from some minor feature, the customer may be happy to cut it out or change it, if it saves them time or cost. It's inconceivable that the customer could've already considered every solution.
  3. Involve your whole team. It's easy to become too close to a project to see the same fresh perspective as an outsider. Many brains is better than one, after all. Sometimes the best answers might come from the most unlikely, non-technical sources, if you can explain the problem in layman's terms.
  4. Draw pictures. Break down the problem into boxes-and-lines on a whiteboard, then see which boxes and lines you don't actually need.
  5. Go for simplicity. You can always improve on it later.
share|improve this answer

Spend upfront time on design. You can fix it faster and better in design than later in the process when there are a gazillion things depending on what you wrote wrong.

And collaboration is most important in design, I think, I've saved many many hours of going down the wrong path by brainstoring with others in design. This is one place where meetings actually help. And boy it sure is nice to know that the guys over heer doing piece x are going to need piece Y from you even though it isn't in the spec. Talking early on and trading ideas can eliminate a whole lot of puzzle pieces that don't fit together.

share|improve this answer

Slow down. I find that rushing things might work in the short term, but in the long term it's detrimental to your productivity (and potentially others' productivity as well).

Secondly, remember that there is such thing as "negative work". A lot of programmers assume that you can get more done just by working more. Anymore, I'm beginning to think that 40 hour workweeks might even be too much. I'd say that I have difficulty putting in more than 30 hours of real, honest-to-god work.

Thirdly, realize that no programmer has ever died from not meeting their deadlines. I'm not saying to ignore them. I'm just saying it helps to have some perspective on things. Once you realize that, the above two things make a lot more sense.

Lastly, do everything in your power to convince your boss, your coworkers not in programming, and programmers you don't know or trust very well that you feel the above is complete and utter nonsense. Even if they agree with you, you make yourself too easy a target when people start playing the blame game. Getting involved in that is a good way to lose your job, never mind your productivity.

share|improve this answer
4  
I'm with you, trying to go too fast causes errors just like working when you are tired does. It's counterproductive to work more than 40 hours for any longer than a week. And that should be rare. Once you break that bad habit of working too many hours, you'll be amazed at how much faster you can do things. –  HLGEM Nov 2 '10 at 21:47
3  
"...realize that no programmer has ever died from not meeting their deadlines". Great quote. Generalized, it can be a great stress reducer: "Realize that no programmer has ever died from [fill in the blank]" => relax, do the right thing, have confidence and hope. –  shaunmartin Nov 3 '10 at 4:55
1  
+1: Less haste, more speed. –  Kaz Dragon Nov 3 '10 at 10:43
2  
As Alfred Motapert said: Don't confuse motion with progress –  user1041 Nov 15 '10 at 14:06

Understand that trying to "do it right the first time" is almost always a futile waste of time, at least if you use the terms the way most people do (e.g., the first thing you deliver to the end customer is a "finished product").

Understand that there will be bugs -- and no matter how carefully you think about the design, how carefully you write up the requirements, how carefully you test the code, there will still be bugs (and major ones) on your first attempt. The larger the system and the more different people you're trying to satisfy, the worse those bugs will be.

To deliver a system that has any hope of working, you need to start small, typically delivering a minuscule prototype that nobody (especially you) thinks is really even close to a finished product. Let the users see and play with it anyway -- and chances are that in a half hour or less, they'll let you know about at least one (and typically more) assumptions you've been making that are completely wrong, so any more time spent on "getting it right the first time" would have been completely wasted.

Don't get me wrong: feedback from users won't guarantee that you get everything right -- but lack of feedback nearly guarantees that you'll get close enough to everything wrong to produce an "instant legacy" system -- something badly enough mucked up that during the introductory training, essentially every user is going to be thinking "how soon can we get rid of this junk?", and things are going to go downhill from there.

Especially when it comes to UI design, you need to deliver early and deliver often. Don't even dream that your first attempt has any hope of being "right". In fact, a user saying any of your first five attempts is really right usually means he's gotten bored with trying to explain how badly you've screwed up everything in sight, and you've missed the point so completely that in the next round you return with something dramatically worse.

share|improve this answer

Learn your Keyboard Shortcuts. I can't tell you how much time that has saved me by being able to hit a key combination instead of using my mouse.

Macros are also a huge help if they're available in your IDE

share|improve this answer
14  
If typing is the thing holding you back, you're not thinking enough. –  Bill K Nov 2 '10 at 23:51
2  
Its not just typing shortcuts, but also shortcuts for things like refactoring or formatting. For example, some I use a lot are ctrl+R,E to build the Get/Set methods on a property, ctrl+E,D to adjust formatting/whitespace, ctrl+W to close all open code files, and ctrl+M, O|L to expand/collapse regions quickly –  Rachel Nov 3 '10 at 12:12
1  
There are no medals for typing. Staying in flow is vital and stopping to twiddle with aligning things because you wrapped something in an if wastes your creativity. Using autocomplete (intellisense or whatever), snippets, auto-expansions, brace/bracket/quote completion keeps you revving and keeps your mind on the concept you are trying to capture in code. –  Kate Gregory Nov 15 '10 at 14:35

One thing came up to me some 5-6 years ago is that you THINK much, much faster than you can write code.

For the sake of example, let's assume that the order of magnitude, when you are fully focused on thinking about the problem is probably a 50:1, if not more .

Therefore it's easy to see that spending an extra MINUTE to think about a possible alternative in your class design/algorithm/function saves 50 minutes of implementation work.

And not only that. Since you've spent as much time as feasible into the design phase, consequently exploring all the venues in problem solving, once you start coding it's going to be VERY STRAIGHTFORWARD, since you will not be wasting additional time exploring solution alternatives while coding - you already have them sorted out in your head!

Since I've been thinking about it this way, I've found I'm much more productive.

On a more humorous note, some years later I finally got my self to read "Code Complete", which clearly cites a research that the cost of fixing software bugs rises in the post-design stages (the waterfall methodology). Since this is effectively the same thing I thought about, I guess the second piece of advice would be to always check what other people might have to say, so as to not reinvent the wheel :)

EDIT : I'd also like to add that for the two points above to fit nicely together, you really need to have true mastery of your programming language (and any no. of frameworks that are commonly used alongside of it). Knowing it inside out will have the effect of your brain automatically finding correct language idioms/framework classes/etc that suit your problem domain best.

share|improve this answer
1  
Interesting approach. –  Helgi Hrafn Gunnarsson Nov 2 '10 at 17:13
5  
@Helgi - It's quite natural when you think about it - our work is so intellectually intensive, yet the script-kiddie-jumpstart-with-our-latest-framework philosophy has pushed aside the importance of intelectual process in favor of putting together lego-bricks of software development. –  Jas Nov 2 '10 at 18:10
3  
"The measure twice and cut once" approach - Think through all the code paths you can and make sure the design works and then code it up. –  Nikhil Nov 4 '10 at 9:41
1  
@naxa - Surely, overgeneralization does happen, more so early in your career, as you gain more experience under your belt, you'll be more cautious as to not overgeneralize and overengineer the problem. 2+ years after posting this answer, I still find this approach working great for me today. The only area where I would recommend "start coding first" is when you're exploring a new technology or a new concept, but in that case, it's not about productivity, right ? –  Jas Jun 5 '13 at 9:07

Remove as many impediments as you can between what you're thinking and what you're producing.

Although trivial, one important place to start is learning the keyboard shortcuts for whatever IDE or editor that you're using. You'll be suprised at how much faster you can go - not just because you'll be typing faster but more importantly you'll not be losing focus whilst you shift from keyboard to mouse and back again.

share|improve this answer

My three prefered techniques:

Decide when you interrupt.

  1. Avoid external interuptions such as emails, phone, coleagues etc.: Have "opening hours".

  2. Take regular pauses (10 minutes for every 45 minutes of work

Tune your engine

I use a combination of GTD and some concepts of the 7 Habits.

Use community power

  1. Don't reinvent the wheel

  2. Don't hesitate to ask the community for solutions

share|improve this answer
6  
+1 for community power "Good programmers write, great programmers steal": codinghorror.com/blog/2004/12/… –  Gary Rowe Nov 7 '10 at 10:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.