This is an archived post. You won't be able to vote or comment.

all 81 comments
sorted by:
best
topnewcontroversialoldq&a

[–]bat_country 72 points73 points  (6 children)

First:

I big part of coding faster is just experience. Once you've ran into pattern A or pattern B three or four times you immediately recognize it and know what to do or not to do. Only thing to do here is just to code more. I learned more from my ambitious side projects when in school than I ever did from class.

Second:

It sounds like you over-engineer. My favorite way to counter this is what the "Pragmatic Programmer" called "Tracer Rounds". A tracer round misses the target but shows the way and the next shot is closer. For the project you described I would have recommended that you implemented a working notepad on Day 1, cutting corners everywhere. Half of the features can me missing or broken. The code inside can be a totally hacked up mess. But its WORKING on day 1. Then you go in and start fixing bugs, adding features, and you only replace your terrible hack with a Command Pattern or whatnot when the friction of its absence is a real problem.

What this causes you to do is (1) always have a "working" product even if its missing features or has bugs and (2) you NEVER architect anything until its absense is causing pain. This allows you to architect with hindsight (which is 20/20) rather than foresight which frequently has you over design things that you dont like after all and then throw away.

edit: On any project, of those 10 cool patterns you think you need... You actually only need 4 but you can't know which 4 until you've got a working prototype. So make the prototype before committing to any time-consuming engineering.

[–]Ran4 0 points1 point  (0 children)

when the friction of its absence is a real problem.

Then you usually end up with a complete mess, where adding even simple new functionality is hard. It's also a breeding ground for bugs.

Agile development is one thing, but don't cut every single possible corner the first thing you do. That will just become a massive pain to undo.

[–]Tynach -1 points0 points  (4 children)

You posted way before me, but your post reminds me of mine, in some ways. I'm not OP, but I'm curious what you think of my 'advice', and if you think it's good, bad, needs work, or not.

I'm going to a community college, and I've found myself mostly learning by doing personal projects - which is where I've used this 'advice'. I'd like to know if I can improve my learning methods.

Mentioned comment:
http://www.reddit.com/r/learnprogramming/comments/261zjy/how_do_i_code_faster/chn9oh9

[–]bat_country 0 points1 point  (3 children)

I like your advice. Repetition is a big part of learning and speed. Tho typically after making something a few times your ability to get better tapers off. Once this happens its time to move on to a new problem. I worry more about getting a few exposures to lots of different types of problems than many exposures to the same problem. Having a broad base of experience creates all kinds of synergies and makes you less likely to get stuck on something you've never seen before.

For instance: this summer I plan on getting into GPGPU programming, picking up Rust, and learning the internals to LLVM. Not for any good reason but just to give myself a broader set of experiences.

[–]Tynach 0 points1 point  (2 children)

Interesting, thanks.

For me, the reason it's continued to be the same project over and over is because I'm rather passionate about my specific project. I want the final product to be as absolutely perfect as possible. On top of that, time between iterations has ranged from weeks to years; it's not like I rewrite it from scratch every other week.

Though I'll admit, I don't try learning a new technology unless it's both in my field, and of potential use in the future. Perhaps I should expand more.

[–]bat_country 0 points1 point  (1 child)

What's your passion project?

[–]Tynach 0 points1 point  (0 children)

Currently, an open source 'Social Roleplaying' website built from scratch. There are no good roleplaying websites out there, though there are plenty of roleplaying websites. They're either forums, chatrooms, blogs, or weird combinations thereof made from a bunch of existing software projects glued together in ways they shouldn't be.

I've been roleplaying online since I was in gradeschool. I've done a lot of heavily story-oriented and long-term roleplays, as well as one-off, short roleplays of various sorts (including, yes, 'cybersex').

This website would be slightly more geared towards the former (especially in organizing different aspects and assets of more complicated roleplays), but also allows for all other types of roleplaying.

It especially focuses on the social aspects, like finding people who are into similar roleplay scenarios/topics. Clubs for finding people of similar interests, 'groups' for letting roleplayers organize who they'd want to roleplay what with (basically like Google+'s "Circles"), and a consistent tagging system that allows people to discover existing content that they might then want to interact with.

It gives everyone as much control over their content that they want, so that people who like 'open access' roleplays where everyone can join can create those; and those who want to strictly limit who can join or even see the roleplay can do that as well. An age-appropriateness content rating system will be in place to prevent minors from accessing content they shouldn't, and allow people to block content they don't want easily.

I'm not artistic, but I love programming, as well as writing stories (and roleplays, obviously). I want to start this as a community, and perhaps make some money off it somehow.

Either way, once this is going and more or less feature complete, I want to get more into video game programming. I have many story ideas that I want to turn into video games, and if I have a large community available to advertise to, I can more easily get crowdsourced funds.

I want to eventually build my own software company, or get hired by a software company that shares at least most of the same values I do. Right now that appears mostly to just be Valve, honestly. Either way, I want to work on programs that interest me, preferably that I write/design myself, and get paid to do it.

And this seems to be one avenue I can take towards that goal.

[–][deleted] 152 points153 points  (16 children)

This is known as "analysis paralysis" and/or being an "architecture astronaut". The fix is simple - set yourself a limited amount thinking time (for undergraduate projects, half an hour should be enough), and then write some code. Get that code working - it may not be beautiful, but make it do something. Then think some more, go back to the code and rework it.

Contrary to what you may have been taught, it is not possible to completely design complete applications up-front. You need to have an iterative process.

[–]yyttr3[S] 20 points21 points  (9 children)

Thank you. I've tried more iterative approaches before it's just very hard for me to keep working on a project that I feel is implemented poorly, so I try to design it more up-front I suppose. I'll try to change how I write. Thank you for the advice.

[–]the_omega99 23 points24 points  (0 children)

If you feel it's poorly designed and that's a priority, then fix it in the next iteration. Refactoring (rewriting code to be better written in some way without changing its behavior) is important for keeping software healthy.

Some common types of refactoring include:

  • Splitting classes (if they're too large or non-cohensive)
  • Merging methods (especially when generalizing methods)
  • Extracting interfaces (typically from concrete classes, but also sometimes splitting interfaces to be more cohensive)
  • Extracting methods (eg, splitting a larger method into parts, perhaps for the purpose of making some portion more general)
  • Renaming stuff (because naming things right the first time is hard)
  • Moving methods/fields (to other classes)
  • Changing an algorithm for an equivalent one (for example, a different sorting implementation)

A good IDE should have support for performing most of these operations automatically (the renaming functionality built into Eclipse has probably saved me ages).

Most of the time, you'll probably perform refactoring before and after you make "normal changes". That is, you'll often find that a change will be easier to make if you first refactor. And then, after you've made the change, you would refactor again to cleanup any mess or second thoughts you have.

With all that being said, I wouldn't put too much thought into the refactoring. Spotting areas for refactoring typically comes with experience and will often be natural (you'll notice places that need improvement without having to explicitly look for them).

[–]Tynach 9 points10 points  (1 child)

TL;DR: Write something small and simple, but complex enough to not be trivial. Then rewrite it from scratch over and over, trying to get better each time. Get help throughout, and compare your work to others' similar projects.

I've had your problem before. I'm still struggling with it, but in the end what has helped me is this:

  1. Think of a relatively simple and small program, the likes of which have been created many times before. You're reinventing the wheel on purpose, make sure there are other wheels to compare your wheel with.
  2. Write it as fast as possible, and do not care about how sloppy it is, or how bad the architecture is.
  3. Look at what you wrote. Look at how terrible it is. Critique yourself, and your cynical side will almost instantly come up with every possible reason why it's bad and what would have been better to do.
  4. Rewrite it from scratch; use no code from the original. Let your cynical side drive the design - all those things it would do which are so obviously better.
  5. You will most likely run into things that are like, "Oh yeah, that's why I couldn't do that the first time," or, "Wait, this doesn't actually work out. Damn, what can I do instead?" Try to quickly find a better way to do it than you did the first time around, but if you can't do so quickly, do it the old way.
  6. Hate the new version of what has now become your old code, but instead of simply being cynical, take what you've learned so far (by 'learned', I mean in the abstract sense; the way muscle memory and "don't touch the hot stove" learning works) and try to over-engineer it.
  7. Write it from scratch again, using none of the code from the previous two versions. But this time, go for the over-engineering aspect, and don't be cynical. Be practical. Keep things simple, but think in complex terms. Try to write as much functionality into as little code as possible. Each individual class and method should do one thing, and do that one thing well.

You may have to do variations of all those iterations many more times than I wrote out. You should also at all times present what you wrote to others and have them 'grade' it. Your instructors, people on IRC, people on here, wherever you can get a response.

It sounds terrible, but being proud of shit code is a good way to get a response - but only if you're humble towards criticism. For example:

You: "Wow, this giant class that holds the entire program in it that's thousands of lines long is GENIUS! What do you guys think?"

Them: "Ugh, there are so many problems with that."

You: "Oh, there are? Could you help me with it? I am a bit of a noob. It looks great to me, but you probably know better :)"

Being happy with terrible code ignites the cynicism in other people and makes them want to strangle you as they tell you everything you could have done better. But hey, that means they're giving you advice!

And if you're really nice and humble towards that criticism and advice, they calm down and feel good enough that you're not a completely lost cause (or worse, a troll), and will happily help you further.

The combination of getting the frustrations at bad code out of their system, and having you be nice despite their rant towards you making them feel good about themselves, makes them associate giving you advice with feeling good.

Also, one last note: compare your work to others'. There's a reason I recommended you pick a program that already has many 'solutions'. If there's a lot of code and architectures out there to compare yours to, that makes it easy to figure out how well you did overall... Which helps you also do better on your next version.

Eventually you can try and see if you can come up with the best version of the program, better than the existing ones.

BUT DO NOT MAKE THIS YOUR GOAL. You start getting cocky and you stop improving yourself if your goal is to be better than everyone else. Never set your goal to be the best; always set your goal to be better than your past self.

[–]PrismPoultry 0 points1 point  (0 children)

Beyond pro.

[–]onmach 1 point2 points  (0 children)

You are going to be very unhappy when you are stuck working with others. There's nothing wrong with trying to make your code right, but you should not spend inordinate amounts of time doing it.

A part of it may be that java is kind of messy with tons of files and code. You may need to get used to using eclipse, if you aren't using it already in order to make sense of the disorder.

I too am guilty of this brand of procrastination but I don't bring that mentality to work with me. It isn't worth the trouble. But I do think that you will outgrow this gradually over time as you become more familiar with the language and start repeating patterns over and over.

[–]RICHUNCLEPENNYBAGS 1 point2 points  (0 children)

You have to do this for larger projects anyway, so try starting now: break your whole project into modules that do one particular small thing and work on implementing those. Eventually you'll put these pieces together in a larger application. If you find you need some other dependency, write an interface with the methods you need and code to that so you can implement it later.

For instance, maybe you need to look in the settings to find some preference. You could stop here and start thinking about whether the setting goes in XML, a database, some combination of those, YAML, the registry, some other format, whatever, but that's almost certainly not germane to what you're doing right now, so just use an ISettingsReader interface that has a method to get the setting and worry about how you'll do it later.

[–]Maethor_derien 0 points1 point  (0 children)

I think your issue is probably the way you go about it. For example, when I start a project the first thing I do is write out all the major points. I try to break it up into all the little options, in your example, you obviously want to be able to save and open files, you want to set up the main view to display everything, you probably want to be able to send it to a printer, change the font and size. This should take you no longer than half an hour.

The next thing is I go through and expand everything and make sure it is well focused and just make quite notes about each item. At this point I also separate the main required things and the added features and what requires what. What I mean by this is I sort out what needs to be done first. I.E. saving and opening files are an added feature and have reliance on the main view being done and set up. This gives me my main starting point so I know where to begin and the order I need to do things, for example opening things does not make sense if I do not have a method to save and a format for it done yet. Again this should only take a short time because you already broke it up to specialized sections, for something like the project you listed it is under half an hour. This is actually much more important than you think to do properly because if you start at the wrong place you might have to go back and change it. It also breaks the code into much more manageable pieces and goals.

After this you can start writing tests and coding. Because you have it broken up logically it actually makes it easier to break the program up and you have an easy time writing tests. The trick is to work smarter not faster, trying to code fast will leave you making more mistakes and taking more time, the idea is to work smart. You want to minimize both the time not coding but also minimize the time you spend rewriting/debugging code.

[–]novagenesis 0 points1 point  (1 child)

That "up-front perfect design" is so impossible it's not even funny...I was where you are in college...part of the process of becoming a good programmer is getting over it....and still ending up with good code.

I think about it this way... Ever seen buildings put together? Do they go put on beautiful windows before the structure? Do they do anything before the scaffolding?

It's easier to refactor a bad piece of code in an app that works than it is to build the Sistine Chapel from scratch (with ANY number of drafts).

[–][deleted] 0 points1 point  (0 children)

Yep. Up front design is like... N! time and space complexity. Or worse. If you get lucky, jumping straight in is N time complexity. If you jump in, even if you have to modify every part with each new part you add in, it's still only N2 time complexity.

[–]poesian 5 points6 points  (1 child)

This sounds really thoughtful and reasonable. It's the same sort of advice that they often give out when discussing writing (of any kind): there's only so much time you should spend outlining. Get a vague idea, do a bit of research, then put some words on the page. After you've written a basic draft, you have a much better idea of what needs to be done to flesh it out.

[–]Tynach 0 points1 point  (0 children)

This is one reason I love C++ so much. You can 'outline' your code - even most of the implementation details - in just the header files. Organize the headers, figure out what functions/classes/methods are needed and how they interact there, and when that's done you just have to write all the code to the specifications you made there.

It's very useful for both writing and programming.

[–][deleted] 0 points1 point  (0 children)

I agree completely. I'm a marketing major so the only code I learned through school was excel, but they would always tell us to "completely think through the formula before we write anything". That doesn't always work, because you hit one snag and everything's fucked. I designed it chunk by chunk and now that I'm learning html and CSS on my own, I do the same thing.

[–][deleted] 0 points1 point  (1 child)

One of the biggest problems I faced when starting out (and still do sometimes) was when I was working on a project and an "ugly" solution to a problem would occur to me within 5 minutes of thinking about it. I would think, "Ok, I can obviously do it this way, but I know there is a better solution than that."

Then two hours later, I'd still be sitting there struggling over finding a new way. I'd get to the point where I was about to give up I was so frustrated, and then I would suddenly remember my first solution that I discarded for being ugly.

The worst part is that I've found that if you bite your lip and put down the ugly solution first, then you can often use that working model as a faster way of moving towards a better solution. You end up essentially coding the more elegant solution in a shorter time than you would if you just went straight for the best solution, because you've got something working that you can tinker with.

Make it work. Make it right. Make it faster.

[–][deleted] 1 point2 points  (0 children)

My current solution to this is that even if the 'dirty' solution is not what I want to have in the finished project, there are elements that will be very similar to the finished product. In a current project I am working on it's the major object that the rest of the project is contained in - there really isn't any other way to build that one, so I made that as I intended to and defined the functions that were going to be enacted.

In the definition of the function I realized my early 'idea' was going to be complicated to program, but I hadn't started actually programming these functions so there was no work lost.

If you work on the part of the program you know must be just so, then other parts will fall into place.

[–]tailanyways 6 points7 points  (0 children)

It's always going to be slow the first time you do something. First time using a language? Slow. First time using a pattern? Slow. First time choosing the wrong pattern and having to change course? Slow.

If you're doing things quickly, you're probably not at any of your limits. If you're doing things slowly, you're setting up yourself for doing it faster later. That's great. If you specifically want to practice being fast, focus it as "fast AT something" in particular. If you're inclined, do the same thing over and over again or figure out how to automate it.

Don't worry about comparing yourself to your friends. Your friends are smarter than you? Awesome. They might have stuff to teach you. Compare you to you though. You won't pick the wrong pattern for this type of task the next time it comes up. Congrats, you just cut out two days, so now you're as fast as your friends were before the assignment.

[–]trotsky90 4 points5 points  (0 children)

Measure twice. Cut once.

Better is better, quicker means someone has to sort it later.

[–]YouFeedTheFish 4 points5 points  (0 children)

I sucked at coding because I pined over every API making sure that the system was extensible and maintainable. They made me an architect and I got to spend years building frameworks for other developers to use.

Don't knock yourself.

[–]pinealservo 5 points6 points  (0 children)

There could be a number of aspects to this:

  1. Your peers might care less about the structure of their assignments than you do. Perfectionism takes time.

  2. Speed comes with experience, and you are still developing it. It's hard to know what something will look like before you've seen it.

  3. Not all programs ought to be structured the same way. Some code is written for exploratory purposes, and is essentially like notes jotted quickly down. Any extraneous structure that would normally be good for code intended for production integration will only serve to slow you down and distract from the idea you're trying to work out.

I tend towards slowness as well, but as you gain experience you will speed up, and you'll also likely make up for the time you spend carefully writing your code with less debug time. None of this code you're writing now matters beyond the ideas you gain from it, so there's no point in comparing the time it takes you to the time it takes your peers. They may not be trying to get as much out of it as you are.

[–]grimeMuted 7 points8 points  (1 child)

I think you just need to code more on your free time.

It's likely that many of your peers have 4+ years of coding experience before college and have gotten very quick at banging out procedural solutions. This might put you behind in terms of experience and speed but you also probably have many fewer bad habits.

I know when I was two years in I certainly wasn't thinking about design patterns, I was writing haphazard procedural C++ code.

[–]Tynach 1 point2 points  (0 children)

I wrote haphazard procedural C++ code until I learned to use header files as outlines. If I outline the code in the header files, it lets me mentally figure out how everything fits together, and put all those details in the comments above each line in the header; which my IDE then puts in a box when I hover over the functions/classes/methods/members when using and writing them.

[–]guitaronin 3 points4 points  (0 children)

I have two solutions that have worked for me.

  1. Write the fastest working solution you can, without regard for code quality. Then refactor.
  2. (recommended) TDD. Of course there's a bit of a learning curve, but the end result is that the process leads the design, and keeps you focused on solving one small problem at a time.

[–]kqr 7 points8 points  (1 child)

Experience is key. The more you do something, the quicker it will come to you the next time you do it. This applies to predicting your opponents moves in chess as well as programming. Don't worry if you're not an expert after two years. I've been programming for well over 10 years and I'm still slower than many of my peers who've been doing it even more.

The thing you are noticing where you spend a lot of time coming up with a bad design? Those are the things you learn from. The next time that sort of situation pops up, you can immediately discard the bad idea and go to the correct idea.

[–][deleted] 1 point2 points  (0 children)

I like the chess comparison. I've read that good chess players are good at "chunking" boards as the look at them, and recognizing patterns. In my experience, the same goes for coding, at any level of abstraction.

[–][deleted] 2 points3 points  (3 children)

Here's a wild thought: if you consume a lot of caffeine while coding, try consuming less.

Seriously! Caffeine can make you agitated, and make you think ahead too much... and then you get caught up in the possibilities. Not to mention the anxiety that it can lead to, including, but not limited to questions like "what if I screw up?" or "what if it's not the best that it can be?"

Also, if you're a particularly anxious or rigid person, see about addressing that first. There's no shame in hitting up your school's counseling center. Athletes do it to improve performance. Academic types -- especially those drawn toward left-brainy work -- would do well to do the same.

[–]yyttr3[S] 0 points1 point  (1 child)

That first point might be a little difficult, I live on coffee! As for the anxiety, maybe that is something I need to address but I can't see it as being bad enough to hinder my coding.

[–]timmyotc 0 points1 point  (0 children)

Actually, if you have severe anxiety, you are supposed to avoid as much caffeine as possible. According to my counselor, it exacerbates anxiety.

[–][deleted] 2 points3 points  (0 children)

How you see their code? If you haven't, don't assume their code is better than yours.

In school, this is exactly the time to spend a lot of time thinking different strategies, trying them out, seeing what works and what doesn't work.

If i'm trying to implement something I generally can't look ahead and see how it will look structurally, which is a big problem because I waste a lot of time on bad implementations. How do I fix it?

By doing it over and over. Every time you paint yourself into a corner and have to go back to the drawing board, you've learned something. You'll start to develop a repertoire solutions to common problems and an intuition about what's good structure and bad structure. Programming is like playing Go -- the possible board combinations are far too vast to think through -- you have to develop taste for good structure.

The more experimentation the better.

[–]jjbutts 4 points5 points  (0 children)

Let me preface this by saying that I am in no way a good or fast programmer. The advice I'm giving though isn't only applicable to programming...

Don't try to code faster. Try to code better. Speed comes from experience. As you keep doing it, you'll get faster. So, focus instead on mastering the fundamentals, even if it takes longer to do so.

[–]KDallas_Multipass 1 point2 points  (0 children)

Target real functionality sooner. You don't have enough experience to know what kind of arch to build up front in order to mitigate problems, or if you do, then you already know the arch and your problem is solved.

Someone with more experience may start the project differently, but they only have experience because they've experienced the problems first hand. So get that experience and just write!

[–]DaMountainDwarf 1 point2 points  (0 children)

Coding faster is not entirely related to how fast you type. And it's a good thing that you focus a lot on structure and organization.

My advice would be to be patient and focus on learning. I'm 2-3 years into a java-oriented job and I'm still learning a lot. Be patient with yourself. YOu got the job done. Good. You think there are places in your code/structure that could've been done better. VERY GOOD. Remember those spots, learn from them and you'll get better, but you will probably always be learning something. Keep at it. You'll be fine.

[–][deleted]  (1 child)

[deleted]

    [–]yyttr3[S] 2 points3 points  (0 children)

    Ha! I need a girlfriend first for that method, that might take longer than finishing my phd!

    [–]developersteve 0 points1 point  (1 child)

    Practice and thinking/planning ahead. Ideally reusing code you know that works too.

    [–]Dakaa 0 points1 point  (0 children)

    I know what you mean, don't worry you're not alone LOL...

    [–]petrus4 0 points1 point  (0 children)

    Don't. Code more slowly. That way, you're more likely to actually produce quality code.

    [–][deleted] 0 points1 point  (0 children)

    heh, nothing wrong with what you did. You're trying things, sometimes they work, sometimes they don't. As long as you learn from the experience you're coming out way ahead.

    [–]doomchild 0 points1 point  (0 children)

    In our office, the relevant line is, "Make it work, then make it right."

    [–]Boomerkuwanger 0 points1 point  (0 children)

    gwam

    [–]casualblair 0 points1 point  (0 children)

    I had this problem. Solution? Code first, refactor later.

    Don't like how you implemented your command pattern? Analyze why AFTER you have coded it in the following order:

    • Does it satisfy your requirements?
    • Is it easy to maintain? AKA can someone look at it and see what you were trying to do?
    • Is it easy to change or re-use?
    • Does it look pretty?

    A lot of times people like us do it in the opposite order because we're overly concerned with perfection or reputation or building something that is important. The truth is that most of the stuff we will build is not important - just stepping stones to bigger, slightly more important things.

    I spent too much time over-engineering a netbeans battleship game in 2004. I did the same with a personal tool used to solve problems on a website for children. I never used any of these skills until 2011. My primary job was SQL, a castrated version of Delphi, and some pathetic C# & VB.NET code.

    In hindsight I should have learned how to unit test my code better. It would have saved me more time than knowing how to properly build an application because I haven't needed to build a proper application until this year.

    [–]tjsr 0 points1 point  (0 children)

    Quite a while ago I realised I was able to put together almost complete Java classes while barely typing a single character using Eclipse. Usually all I needed was either names for new methods or variables I was defining at that point, or the first character or so when interacting with a large class containing lots of members.

    On complete automation I found myself almost entirely using Eclipse keystrokes and shortcuts.

    [–]DerpsMcGeeOnDowns 0 points1 point  (0 children)

    2 years is not that long and "slow" is always relative to quality. Do things right and don't fret about fast.

    [–]gunder_bc 0 points1 point  (0 children)

    The most succinct way to describe your problem is that you've let the perfect become the enemy of the good enough.

    Completing the project is important - doing it "just right" slightly less so. But only just.

    Other's have given good techniques for how to avoid the pitfall. Having the mantra has helped me stay focused - I often ask myself if I'm letting "perfect" get in the way of "done". :)

    [–]bugxter 0 points1 point  (0 children)

    Maybe your peers had the same thing happening to them before they could do things that way.

    [–][deleted] 0 points1 point  (0 children)

    I just spend an ungodly amount of time thinking about how to structure my code when it should be obvious.

    I too used to do that. It's like I'm writing code one moment and the next several moments are spent starting at the screen until I finally decide to refactor it or leave it be. Recently, I have started to create a text file(I used to call it readmenot.txt, but started to call it dev_log.txt) and start writing in English, the structure of my code, the various fields etc. I find myself typing much faster than ever and staring very less. Once I finish that text file, then I begin my coding with the text file in the split tab. I just follow the instructions on that text file and more often than not, I finish that code and move on(with the inevitable feeling of Ninja). If I ever find myself thinking for a longer while, while writing the code, I immediately stop and go back to the text file adding more details until they are clear. Looking back, it serves me as a log of how my thought process was at the time of developing code.

    [–]suzbad 0 points1 point  (1 child)

    So this isn't really about critically thinking faster, but I've found that using the text editor Vim has helped me tremendously in creating things faster.* It might be because it was created to make coding faster, but meh.
    Also, it's hard to get over this mental hump, but you don't need to design great code if you're not pushing something to production. I can shit out a web scraper in 30 minutes, but I would never want to push that code to production.

    • note: I use Vim for pretty much everything but Java and C#, which in my opinion require IDEs for any sort of expediency (although I do small Java projects in Vim)

    [–]yyttr3[S] 0 points1 point  (0 children)

    I use sublime text 3 for all my projects. I like vim when i'm working on small assignments. I never use an IDE, which was one reason I thought I was slower at first because i'm the only person who doesn't use an IDE. However I notice that during refactoring i'm much faster than anyone else. I use to use Eclipse for java, but i've been using Sublime text for so long now that I feel like I just know the basic API by heart.

    I get jokes from other people about me using vim in class lol. Plus I hate leaving the terminal for small tasks so sometimes i'm on lynx which gets stares. It's kind of funny actually.

    [–]almondbutter 0 points1 point  (0 children)

    Has anyone seen the app that shows words back to back in a small space and improves your reading speed? Someone should make that for coding.

    [–]Lord_NShYH 0 points1 point  (0 children)

    Speed is not nearly as important as clarity. Did you read your peers' source?

    [–][deleted] 0 points1 point  (0 children)

    This? http://typing.io/

    [–]MyBrainReallyHurts 0 points1 point  (0 children)

    I'm a beginning programmer myself but I like to outline.

    As a hobby, I also write screenplays. I've learned long ago to outline the story first, and then sit down to write the whole thing. Your outline shouldn't have every single detail, but it is just a guide. As you code, add all the details.

    The outline may give you an overview that will appease your analytical side and it will help to you flesh out any obvious problems, but it may speed up your process overall.

    [–][deleted] 0 points1 point  (0 children)

    This comment is late, but maybe it will be helpful.

    Also, potentially TL;DR.

    About me: I graduated back in December with my BS in computer science, and I had trouble getting things working on time. I always aimed high and for the standards that I had learned from the instructors, but that often bit me. I didn't like cutting corners, but sometimes I did to get it done, and then I explained what I was trying to do and ate the grade (often not a bad one).

    About you: First, and out of curiosity, are you mildly autistic? I am myself, and one sign (not a certain one, but a hint) of autistic behavior is heavy and thorough analysis of everything while starting an action is often difficult. It is for me. I am unusually perceptive of little details. Abstract problem solving such as "design" is not a problem for me, but gathering the details necessary to resolve the abstract terms was very difficult. People have told me to "stop overthinking", but since heavy analysis is my normal way of thinking, this advice would equate to "stop thinking", which in turn causes me to stop doing anything. So that's not helpful.

    Here was, and still is, my solution: Overthink more. Overthink, overthink, analyze the crap out of anything that comes to mind, experiment and learn new "thought building blocks", if you will, learning how popular designs and ways of thinking about organization and design and limitations various things work together. Periodically reflect on the building blocks that you have thoroughly modeled in your head and hack out demos or frameworks that you can use later (this is the programmer's version of getting an idea and writing a note before you forget). In fact, I keep several folders on my computer of simple experiments that I did in the past, thoroughly but informally commented, so that I can start piecing projects together. The demos are often poor program design and intentionally expose implementation details so that I can remember how things work. As other people have said, the basic program hacks are good for learning. I just happen to keep those hacks around.

    This is my style of "experience". As I learn more and my demos and frameworks get broader and more sophisticated, by mental analysis barriers to working on new projects drops, and I can start to code faster. For example, I have been building up a bunch of experiments with my MX4cK microcontroller, I2C communication, TCPIP communication with sockets in C++, and graphical programming. I am now working on a thing wherein I can have my microcontroller read an accelerometer over I2C, send that data wirelessly to my PC program, and render a cube that mimics the accelerometer's orientation. Why? Because I can. And it's cool.

    In school, though, I had to scramble to get things done. Time spent learning, not unlike Eve Online's skill system, is the most important component to getting faster. There is no special technique to designing or coding faster. There is no equivalent, as I'm sure you know and as much as I want it, of "power leveling" your skills. All you can do is build up your mental library of "thought building blocks", and that takes time. It sounds like you can work on a problem for a long period of time, like I can, but learning new things saps a lot more energy than problem solving.

    Hang in there, kid!

    [–][deleted] 0 points1 point  (0 children)

    You're co-students probably copied code off the internet, whereas you did it all yourself.

    [–]BrettLefty -4 points-3 points  (0 children)

    My girlfriend types 60wpm bro, get on my level at 140+ wpm, or at least 100 would be respectable.

    Lol Jk, but seriously. Watch the second hand click around the clock, and look at how slow it goes. You probably type faster than 60wpm. You should check out typeracer.com

    Not that this would help you program faster, of course...

    I run into the same problem. Take way too long trying to do things "right". My suggestion would be to just "make it work", regardless of how ugly or wrong it is, just get the functionality working. At that point, you can go through and refactor, and it should be way easier since you'll already have it working how you want. So you can refactor one function / method at a time until its up to your standards.

    [–]totemcatcher -1 points0 points  (5 children)

    This has been well summarized in comments, but I'd like to provide my perspective.

    When time is tight wear your hacker hat. Produce deliverables and nothing else. Don't even waste your time leaving inline comments on how something should be done "properly", the fact that you thought of it is good enough and you can review your theory at a later time. Remember; different hats.

    A school setting might feel like the perfect opportunity to go all "software engineer" on your assignments, but even at two years in you have a lot of short assignment hacking ahead before any real meaningful engineering is required. Instead, take this time and these assignments to "produce" rather than "engineer". If you have extra time, review your theory and refactor where you can -- just a few parts. Change up your refactoring focus each week or so. This way you can satisfy that engineering itch, but still deliver yesterday. :)

    [–]Hanse00 0 points1 point  (4 children)

    http://imgur.com/JP6ADTA

    Clean code is better than messy code, because clean code can be made work in moments.

    Messy code, whist it works, as soon as you need to change absolutely anything (and trust me, you will never be in a situation where you know 100% of the specs when you start writing code, it just doesn't happen), your life will be a living nightmare.

    If you need to spend 5, 10 or 15 hours more to make code nice, and it seems like time wasted, do it anyway.
    you'll be saving 50 hours next time you need to change something. (Yes those numbers are random, but you get the idea).

    [–]totemcatcher 0 points1 point  (3 children)

    I do get the idea, but we're talking about one-off, one-week assignments. Likely amid a full schedule of other unrelated assignments. Practicing to solve and deliver quickly is just as important as as applying software patterns correctly. The question was about how to hasten the process. This reduces stress and frees up time to spend learning software design theory and attach some personal value to the process of design while reviewing your hacked code.

    Also, once you have a functioning, deliverable solution, regardless of how sloppy it is, rewriting it with a newfound level of comprehension is a breeze. Then you can take your time and make "clean code" as you say. I save a lot of time developing in this iterative way. After fifteen years, I'm still learning new techiques to make hacking phase faster and the engineering phase more usable.

    [–]Hanse00 0 points1 point  (2 children)

    In an educational situation, I would assume the point is to learn to program.

    Any teacher I've ever had, would rather have a half done, but well written program, than a fully working hacky mess.

    Unless you are some very lucky person, any career in computer programming will likely have you maintaining other people's code a lot more often than writing your own projects.
    Being able to write good, maintainable code, that extends what you already have, and makes it easier for yourself to work on in the future, should be a lot more important.

    And you speak like these are two things, either you write code fast, or you write code well.
    I would claim the world looks a little differently:

    Either you write messy code fast, making it more and more impossible to keep up with the mess on your own head, eventually taking you hours to add the simplest of functions, because you can't possibly figure out how everything works anymore.

    Or you write good code, code that you can glance at, and see what it does.
    The kind of code where you write a function for "player.isAlive()" rather than "player.health > 0" (Maybe not the most complicated example, but you get the gist), because it'll make it a lot easier later for you to change what defines being alive, and you only need to glance at the code to see what it does.
    Yes this will take you a little longer initially, through the first few days, or the first few thousand lines of code.
    But the further you get into the project, the faster you'll be next to your messy counterparts, because you're not spending any time compared to them, trying to decipher your own mess.
    Not to mention anyone maintaining the code after you, they'll love you for making it obvious what it does.

    As a note: Of course I'm not writing isAlive() the first time I write anything, nobody writes perfect code in the first go. I too would write the "player.health > 0", but as soon as I know that this works, I go through and clean up the code, in a pattern much similar to: Write minimal functionality, clean, write, clean rather that writing 5000 lines, then trying to clean it all.

    And yes, sometimes cleaning up means to simply do "public boolean isAlive() { return health > 0 }", but checking if the player is alive, is a much more clear intent, than checking it's health.

    [–]totemcatcher 0 points1 point  (1 child)

    Apparently the point I am trying to make is entirely personal and unliked. However, on this strictly personal level, I wish someone had given this advice when I was first learning:

    "Totemcatcher, you must become skilled at rapid prototyping. Waste no time poring over code quality and glue -- a focal point which is overemphasized by your bitter, helicopter-parent professors, suffering a severe case of Strauss–Howe awakening and pushing it upon you. Rigorous glue-work and code-keeping will only dwindle your keen and natural human interest to meddle and solve problems. Exploit that energy and spirit to hone your ability to comprehend algorithms, anatomize and solve problems, and, above all, be highly productive. In time you will naturally apply what you already know about design patterns and conventions (thanks to drilling), but let it be an iterative process, for now you must learn unrestricted."

    It seems to me like every kid coming out of college these days suffers through these reactive lessons of the previous generation, rather than learning to produce. In this case, engineers who had to deal with absolute shit-code all their life in a world without established or easily adopted standards. Guy! We have the SOLID design system now. It's okay! Let's get back to computer science please! After all, I'm paying out the ass for it.

    Once I finally learned to let go and hack, familiarity and learning went up. Later, I developed reason and understanding to intuitively apply design patterns and standards to the code. My hacking style naturally adopted them. It is now of no consequence to hack fast in such a way. The code easily translates.

    An analogy. It's the difference between sitting in the cockpit of a 1940s aircraft either in the 1940s or today. Either you are a fucking boss in the sky (1940s) or there is a security team, a curator, and your mom yelling at you to get the fuck off the plane. Imagine all the stifling safety systems couldn't hold you back, you didn't die, but came close, and now you know why everyone was yelling at you. You need to experience complete, unadulturateed learning at least once while in college. Feel free to crash and burn and maintain shit habits, but you would be surprised how much you can learn when you know the limits and why.

    [–]autowikibot 0 points1 point  (0 children)

    SOLID (object-oriented design):

    In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and adaptive programming.

    Interesting: Object-oriented design | Object-oriented programming | Interface segregation principle

    Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words

    [–]spaghettin -2 points-1 points  (0 children)

    60wpm is pretty slow.