Tips for working fast [closed]

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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

Answer 17

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

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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. :-)

Answer 23

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.

Answer 24

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. :-)

Answer 25

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.

Answer 26

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.

Answer 27

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.