Hacker News new | past | comments | ask | show | jobs | submit login
[deleted]
on Sept 13, 2015 | hide | past | web | favorite



I think another question to ask yourself is, why do you feel this isn't normal?

If others claim they could do the task faster, consider that programmers chronically underestimate.

If you've seen others do it faster, it's possible that they are taking shortcuts, making quicker decisions that will involve more work later. From your example, you've carefully picked a library and thought through how to integrate it properly into your code - these steps can be skipped for speed, but the cost usually isn't worth it.

There are always going to be better programmers, but they're often not the ones who claim to be great, or fast, or rockstars. So I'd just check to make sure you're not making unfair comparisons of yourself.


I had the same question. Is taking a whole day to set up an authentication system for a web application unreasonable? That's a pretty critical component and not necessarily simple. At my, erm, last company, it took multiple developers three months to set one up and we're still tweaking it.

I'm with @funkysquid. A few extra hours to properly implement and test code that is going to see months if not year of critical frontline service seems like a bargain to me.

Now if your managers are of a different opinion, or you're taking an extra long time to produce code in the end that still has a lot of issues, that's another matter.


Agreed here too. I graduated first in my class of 200-odd engineering students, then completed a Master's degree with a perfect GPA and a couple papers published (on top of my thesis). A couple years later I started web programming, eventually building a relatively successful web-based business. Nothing in the OP sounds like a symptom of slow thinking to me. Doing something reasonably complex with unfamiliar tools should take a bit of time. In fact, being able to keep focused and get something like that done in a single day sounds pretty impressive.

Sure, if you already know the library you're using inside and out and have built such a thing before, maybe you could whip it out in a couple hours - maybe - but a day really isn't that long.


if you already know the library you're using inside and out and have built such a thing before, maybe you could whip it out in a couple hours

This is the key, I think. I was in the same boat as OP not so long ago in thinking that I was unreasonably slow. I'm not; I'm just a generalist.

People who specialize in one specific area of technology can bang out something in their wheelhouse in a few hours because that's all they do, all day, every day. It makes them seem like superheroes. If you're working on a team with all specialists, it can make you look even slower by comparison.

As for what to do about it, I'm stuck between either finding a specialty, going into management, selling my own software products (ie: work for myself) or finding a way of communicating my work in a way that makes me look like a superhero too.


If you've seen others do it faster,

Also consider that they may have used that library previously.. so you don't get to see them spend a whole day making mistakes with it and trying to get it working.


You may be chronically sleep deprived and not realize it. If that's the case you should try sleeping really consistently for a week and check the difference. Don't use an alarm, just be really disciplined about going to sleep early enough to wake up naturally. No caffeine or other stimulants.

The difference between a well rested brain and a sleep deprived one is night and day.


> The difference between a well rested brain and a sleep deprived one is night and day.

When I don't get 8-9 hours of sleep, I code exactly the way OP described. Things that normally take an hour, take a full day because I can't focus and miss the most embarrassing, basic stuff.


Agreed. But don't do the comparison anytime in those weeks the US Open is on at Forest Hills, LI, NY. Those weeks the entire country, world (?), suffers insomnia. It's the attorneys in the tennis clubs packing in to watch the tournament, packing that white powder up their snouts to be sharp and quick on the retorts to other attorneys. Not to mention the well heeled fans at the events proper. That's my opinion. Sleepless during the US Open. I don't play tennis and certainly don't watch it. Who knows, maybe the 9/11 terrorist attack was about the two towers representing two tennis players at the nearby USOpen, then ongoing as it does same time every year. Terrorists fed up with the yearly insomnia period.


Can't upvote that one enough.

You need enough sleep, you need good sleep, and regular sleep.

And then you need down time. The time where you're not expected to rush to do something. Where you can sit down and learn a bunch, or pick yourself up and take a stroll.

You _need_ walks.


This is really great advice. People overlook the importance of sleep.

I'd add that it's worth spending some money on a decent mattress, great pillows, and tracking just how restful a sleep you're getting. The return on investment will exceed just improving speed of decision making.


I have the same annoying problem,and this seems to be my living pattern


Don't forget to throw in an hour of good physical activity per day for the test week


I would get assessed by a psychologist if you really think your slow. You might get surprised and just find out your actually not. Or your smart and meticulous (more accurate, but slower), something pretty common in software engineers. Software requires high preciseness, being loose and sloppy quickly gets filtered out.

The example you cite sounds like a lack of experience with the library set. The reason it's a 10s fix is because he's seen that shit before, not because he's smarter. The engineer is applying a heuristic, the heuristic was correct and thus they solved it quickly. You start to notice general error patterns in computers from experience, and certain error patterns in certain libraries or programming languages.

For example, I notice a stutter in a UI application. My guess when I see that is something is probably being processed on the main thread that takes too long, because I've seen that before in my own programs. I've just reduced my search space significantly. My heuristic might be incorrect, and my search time becomes larger.


I'm a lot like OP myself. I take a lot longer than others to get something off the ground, but when I do, it's very well executed, and I understand all the moving parts inside. But then again, I'm obsessive about every small thing.


I concur.

However, to me, this is the most evil curse, especially at uni, where instead of doing an intelligent thing you can just set up a tree of 20 one liner if statements shudder And still get a 100%

Probably it might be like that at work too...


Slow is fine. Don't worry about it. Nicotine, and cholinergenic smart drugs like the racetam family and substances like centrophenoxine can boost focus memory and learning temporarily but really you likely only have a perceived deficit. We're not super human - none of us. A few might seem smarter or better or faster or whatever but interest and careful slow observation will almost always win out, and they're likely that way because they've already gone through the period of being slow to understand the details, and are now fast. Don't move so much - stick around at a role for a while and you'll likely then be the alpha giving noobs a hard time for being slow.

I used to think the same thing. Now I'm not sure if I'm insanely smart and fast or stupid and slow. I'm working on a contract at google and it flip flops back and forth about 20 times a day. My friend once said "being a developer means feeling like a genius and a complete idiot at the same time all the time"

But really, only an objective medical advisor can tell you. Even then, it's pretty subjective what you're asking and analyzing. Believing it may in fact be a cause - maybe you're obsessing and worrying about being slow and that belief and anxiety itself is hampering you. Who knows? Nobody will be able to tell you if you're faster or slower than your peers. Even you and your peers side by side would have a hard time saying that because you'll know one little section better than them and be faster there for sure.

Beware your own attitudes! Have you ever heard of this? https://en.wikipedia.org/wiki/Impostor_syndrome

Impostor syndrome[1] is a psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be. Notably, impostor syndrome is particularly common among high-achieving women.[2]


Do you have a link for [2]?


It's in the wikipedia article.


"The time seems to be lost mostly to choosing between options (such as libraries to use), in deciding how to integrate those libraries into my source code, and in solving random hiccups. If the library just doesn't work for no apparent reason (like I always get a login failed message with no clear exception) there goes another three hours of debugging something that would have been an intuitive 10 second fix to a faster developer."

That sounds pretty normal: working with new code is always harder and slower than working with code that you know well. It sounds like you're constantly climbing that learning curve by using new libraries. What if for your next project, you just decided in advance to use the same libraries or frameworks that you used in your previous project? Then you'd have already worked out all the bugs and API oddities and can immediately start working on implementing the actual project.


>They don't make a pill for slowness

They do make a pill for slowness. Several, in fact. In subjective order of strength, modafinil, methylphenidate (Ritalin), and amphetamines (e.g. Adderall aka speed). Not that I'm suggesting these, but it's not called speed for no reason, yeah? It is not just for ADD people; the benefits to everyone else are immense (well except potential heart problems and psychosis.)

You should definitely follow the other suggestions, like verifying that you're truly operating slowly (it's difficult to accurately judge oneself). And making sure you're healthy, etc.

The stuff you are describing though, it sounds more like unfamiliarity. If it took you three hours to debug something, why was that? Are you following a scientific approach in debugging? Analyze and get feedback on how you're missing things. I spent hours debugging an app that I wrote and it all came down to a one-line fix. I was just unlucky.

Edit: You can check erowid out. From developer friends, I've seen them: 1. Read hundreds of pages of material in a single setting, at a fast pace, far beyond normal ability. 2. Ability to do math/calculations increases several fold. 3. Output soars once focused on a problem. 4. Grand-scale ideas (sometimes even workable.)

The big downside and why not all devs should be on it all the time is the tendency to lose sight of the big picture. Like spending all day optimizing for TLB-hits... in PHP.


I have been on Ritalin since last 3 weeks when I got diagnosed with ADHD. I used to be a dysfunctional developer before this, and things are not very different now. Earlier I used to be able to write some stuff up, but I now I just let it slip up and ADHD seems like a good excuse.


Talk to your doctor. You may need to increase your dose, or you may need to try Adderall or Dexedrine instead.


You are a n00b. Don't worry about it. You might think you are not. You might even think you have a shit-ton of experience because you wrote your first program when you were 5 and you've got a CS degree and you have worked on many personal projects and some freelance stuff. But your lack of self-confidence and your view of everybody else's mental processes show that you are new to the industry, you might be suffering from impostor syndrome, and your boss/employers might be taking advantage of that by giving you the n00b treatment, which basically consists on assigning you titanic tasks you are not prepared to do and leave you to your own devices, requesting that you finish them in what would barely be enough time for somebody who has done it a million times already (and charges a much higher rate for doing it). You are cannon fodder. You will either get through this phase and move on to the next level where you can accurately assess your competences and delegate to your underlings whatever tasks you are not fully capable of doing efficiently yet and don't care about; or you will burn out, give up and let your career die. I don't think you have just discovered you are not a genius. But not everybody in the industry is a genius. In fact there are very few, and soon enough you will be spending most of your time battling with less experienced, less competent people suffering from Dunning–Kruger effect delusions and their clusterfucks. Because they are the fewer, but boy do they mess up.


Tell me more about your experience as a junior developer last year.


My business partner is an exceptional programmer. He's well known in his field, so it's not just me that thinks this.

Sometimes he solves difficult problems seemingly very quickly. Sometimes he takes 5 hours to write 3 lines of code. And sometimes, he thinks it'll take half a hour and it ends up taking all day.

I was talking with him about this post and he says that there wasn't any information in the post that would suggest that the poster is particularly slow. Some things just take a while. Eventually, you'll develop better instincts and form mental shortcuts and you'll get faster at debugging. Especially at debugging, which really seems like an art form to me.


You need to speak with your doctor first. You may be out of shape, you may have a vitamin deficiency, you may have something complicated. The answer is in a doctor's office, not HN.


[deleted]


Earlier posters have mentioned getting enough sleep. If you are affected by sleep apnea, you may be getting enough hours of sleep but it won't matter due to the affects of sleep apnea.

All the reputable medical websites have good articles about sleep apnea -- certainly enough for you to have an informed conversation with your doctor.

Most insurance plans will require a doctor to refer you to a sleep disorder specialist, followed by a home sleep monitor test, then a overnight sleep lab study.

If you ask around, you'll probably be surprised about how many people have been diagnosed with sleep apnea and are probably using a CPAP machine at night to address the problem.


My point is no one can know what your issue is. It takes tests, experience and knowledge of medical professionals to find out what your issue is. If you are open about your symptoms, your feelings and your concerns a good doctor will order tests. They might show something or they might show nothing. The doctor might consider it to be psychological instead of physical so you might be referred to a therapist.

Diagnosing humans is pretty damn hard and will take time. Stick with finding a solution.


Diabetes will also affect mental clarity and vision.


I suggest motivation. This slow cognitive process thing just sounds like an excuse, do the best you can in that moment and forget this story about slow cognitive processes.

Check out: http://www.amazon.com/The-Motivation-Hacker-Nick-Winter-eboo...


I program slower so that I am more productive. The cheap hack can be fast but it quickly becomes technical debt. The fix is already in, so don't fix anything -- maybe refactor. How do you eat an elephant? One byte at a time.

I am still building the authentication system for a web application. It took me half a day and there are bugs, many bugs -- they don't show up, but I know they are there. It should have taken me AT LEAST four days. Speed is relative. I bet you do some things incredibly fast without realizing.

On the other hand, we have yet to build the hundred year language. Some say it will take a hundred years! Others say it is JavaScript and it will be around for a hundred years. I am building my own one hundred year language. It is a programming language/tool/paradigm to allow me to still program when I am one hundred years old -- I call it the hundred year language.


Don't beat yourself up. Seriously. A lot of the other comments are about how you might not actually be slow or how you could fix things with medicine/etc. These aren't bad but may miss the point or be overly optimistic. You might legitimately have a crummy situation (though I would be surprised if you aren't being overly critical)

Please do yourself a favor and stopping beating yourself up. It might not be the worst idea to try talk therapy.

What does your boss think? Do you get negative feedback at work? I actually am pretty slow but make up for it partially in quality.

Either way me being so hard on myself wasn't helping anything. That doesn't mean rolling over and accepting (self-perceived) mediocrity. It just means having some compassion for yourself.


>To given an example it can easily take me a whole day to set up something as simple as an authentication system for a web application

If you are writing your own, it should take more than a day. You can't just slap it together and expect it to be right. That's why there are companies like Stormpath.

What you probably need to do is work on building some reusable library of personal code so that you can get shit running faster. Base it off one of the major frameworks and just make some boilerplate projects that you can check out and get up and running fast. Try to reuse code. You don't have to write reusable modules to reuse your code. Just have a skeleton project that makes things faster.


Like other posters here, I think your description does not sound like you are particularly slow. But even if you are, slowness is something that needs to simply be worked on--not despaired about. As my adviser in college used to say: turn your weaknesses into strength.

That may sound ridiculous when it comes to something like being slow to grasp concepts. It is something I have been struggling with as I've taken to studying Calculus almost 15 years later than most people. But I have been greatly encouraged by some of the things Barbara Oakley has to say. Here is a quote from chapter 12 of her book A Mind for Numbers, "Learning to Appreciate Your Talent":

If you are one of those people who can’t hold a lot in mind at once—you lose focus and start daydreaming in lectures, and have to get to someplace quiet to focus so you can use your working memory to its maximum—well, welcome to the clan of the creative. Having a somewhat smaller working memory means you can more easily generalize your learning into new, more creative combinations. Because you’re learning new, more creative combinations. Having a somewhat smaller working memory, which grows from the focusing abilities of the prefrontal cortex, doesn’t lock everything up so tightly, you can more easily get input from other parts of your brain. These other areas, which include the sensory cortex, not only are more in tune with what’s going on in the environment, but also are the source of dreams, not to mention creative ideas. You may have to work harder sometimes (or even much of the time) to understand what’s going on, but once you’ve got something chunked, you can take that chunk and turn it outside in and inside round—putting it through creative paces even you didn’t think you were capable of!


Honestly, you are meticulous not slow. If I can give any general advice it would be reading and applying some debugging best practices with (strong emphasis on this point) work for you. You don't get clear exceptions? Force highest possible verbosity and debugging level. Something works (breaks) only in specific conditions? Go crazy with unit tests and work on the gathered data.

It worked, and works, for me but served only as an annoyance to some of my co-workers who had a lot more experience with testing and debugging.

It's like with integration during Calculus, people who either know some set of techniques or have some previous experience will look like mathematical prodigies when compared with others. Said others likely tackle this problem for first time or don't see some analogy with previous examples. This is the difference: making correct comparisons and finding similar / known cases. In two years you will meet new developers who will ask you how come you are concluding such wild solutions with blazing speed. They would never even assume that this is where they were supposed to look in the first place. As far as my experience goes, it works for maths, cooking, chess and programming.


1. You might be having something known as Sluggish Cognitive Tempo. https://en.wikipedia.org/wiki/Sluggish_cognitive_tempo For which there is no known treatment, I think.

2. Or you might be of ADHD-PI type. Either way, you need to consult a doctor and get his opinion.

3. A third possibility is that you might be having a hypothyroidism issue or even 4. vitamin deficiency. http://www.medscape.com/viewarticle/723663_7

Strenuous aerobic exercise is something that might help. Mindfulness Meditation will definitely help but its not very easy and you have to invest time, energy before you see results. Also you need to learn it from an expert (preferably) and not from youtube.

Other than these; obsessive repetition could be the key as well. Keep repeating every small thing 100 times till it becomes a second nature.

tldr; Go visit a doctor and take this issue very seriously and debug it by filtering out the possibilities.


>The time seems to be lost mostly to choosing between options (such as libraries to use), in deciding how to integrate those libraries into my source code

I think you're beating yourself up too much. A lot of good programmers feel the same way. [1][2][3] If you haven't done something before, it's going to take longer[4]. Also, spending more time initially isn't bad, if it will save you time in the future.

Part of the reason, you might feel that you're lagging, is that the landscape changes so fast. In another thread, someone pointed out the most productive programmers use a stable set of tools and know them inside out. [5] If you have to keep learning new libraries, this will slow down your productivity. Also, contra to what another poster said, taking notes is a good thing. I frequently come across situations where I feel I've done something, so I look back at my notes or git commits. If I have to make all the same mistakes again, it will take 3-4x as long.

1 - http://www.stilldrinking.org/programming-sucks

2 - https://the-pastry-box-project.net/ed-finkler/2014-july-6

3 - http://www.marco.org/2014/07/11/developers-dystopian-future

4 - http://prog21.dadgum.com/209.html

5 - https://news.ycombinator.com/item?id=10011689


I am exactly like you. I have been doing this thing from about couple of years, and I also think I am not getting anywhere. I have lost most of the interest that I once had for programming, and I just sleep and take meds for my ADHD now. I don't program a lot these days. So, thanks for asking.


You might be depressed. At least, that was the case with me when I started sleeping all the time and lost interest in programming. I finally got the courage to explain it to a doctor, was prescribed some meds, and a couple months later was back to normal.


Try memorizing a ~100 or less code. It may be an algorithm or something fundamental in computer science. You'll notice that it would take a long time to digest it in your head but just keep on trying (I actually memorized it in a month.). Just keep on repeating until you can recall all the code. Eventually, when you've memorized 70% of the code, you'll feel that it is simple to repeat.

What I'm trying to say is that while you keep on doing something repeatedly, your brain absorbs it. Your example could be difficult and time consuming at first. But when you keep on doing it repeatedly many many times you'll realize it to be simple. That's what training is.

Vim/Emacs users can understand what I mean from when they started using it the first time until using it for years.


Introspection probably isn't a good way to assess this.


What assessment is appropriate? I feel strikingly similar to the OP.


> I feel strikingly similar to the OP

I'm glad you said that. If you feel comfortable doing so, could you share an anecdote? If a few people describe this from different angles perhaps more will come out of the woodwork and offer some solutions.

I think the person you were replying to was gently suggesting to see a psychiatrist.


Sure. This is an extreme example. I'm just starting my third of university software engineering and I've been dreaming up a moderately ambitious (but technically straightforward) CRUD web app since early in my first year. Since then I've flipped and switched between countless frameworks and languages, shelved, reassessed, unshelved, reshelved, and scrapped many basic prototypes. Only recently I've made some progress towards a prototype I'm happy with, but most of the motivation for that came from a recent successful launch of a service spookily similar to my concepts.

Not sure how relevant it is, but I've also had to retake multiple theory courses in my time at school so far. Calculus, linear algebra, discreet structures.

In terms of seeking professional help, I'm seeking some myself this week, though admittedly for social and general anxiety (related or not to my productivity, I'm not sure).


This is analysis paralysis. It's not a mental deficiency, but rather an anti-pattern usually brought on by insecurity and lack of knowledge about which decisions are actually important:

https://en.wikipedia.org/wiki/Analysis_paralysis

The way out of it is just to pick something and see how far it takes you, accepting that you may have to backtrack and redo stuff in the future. There's this myth that experts got that way through good decisions; no, usually experts got that way because they made a lot of bad decisions really quickly and dealt with the consequences, and so now they know not to make them again.


Exactly. A quote I read recently: "Successful people are those that make mistakes when nobody is looking"


The way this works for me is that ideas in and of themselves are easy: you have a mental image of how it works (a web page!) and maybe articulated a few sentences about how the parts fit together. The thing is, implementation is much more complicated and tedious than this. "Oh, a site with users, posts, likes, tags, and search." Then you start getting into it and parts start taking you a week and then your brain starts tumbling over itself, conflicted between how easy the idea is to explain and how involved the production of it is.

Let's go to the redoubtable Yegge and his concept of "Shit's Easy Syndrome":

http://steve-yegge.blogspot.com/2009/04/have-you-ever-legali...

Stick with it. The set-up is long, but it pays off handsomely.


See, I'm out in the industry now but back when I was studying I could have written almost exactly the same thing. I wish you all the best.


+1


Not sure if you looked up "sluggish cognitive tempo" on Wikipedia yet. Give that a read. Have you experienced a head injury in your life's? I experienced a traumatic brain injury after being hit by a car in my early 20s. I never returned to my former cognitive pace until I was diagnosed with ADD by a doctor who couldn't say for sure that it was caused by the head injury but who suggested I try a mild stimulant to test the result.

The stimulant did the trick. I got my life back. Talk to your doctor and talk to a psychologist or neuropsychologist.


Does your team do estimates in advance for how long a task should take or is it cowboy coding just creating random features the customer might want? If you have estimates, do you overshoot them or what is it that quantifies you as being slow? I would recommend breaking tasks down and giving each task an estimate that you should try to follow, with clearer goals and clearer deadlines its much easier to keep on track, the unit for estimating should be nr of days, not hours or minutes.


I don't think the power to quickly do things like you're describing is a cognitive ability. The more of your job you can move _out_ of the "thinking" part of your brain into the habit part, the more quickly it goes.

Being a "regular" software engineer is all about building a large internal collection of idioms that you can reach for to build what you need, not to methodically think through each step.


Being a "regular" software engineer is all about building a large internal collection of idioms that you can reach for to build what you need, not to methodically think through each step.

Are you sure about that? It seems backward to me. Each time you implement something, you should be improving yourself. This means not relying on just doing it the same way you've always done it. It means actively looking for a better solution this time around, which typically means methodically thinking through each step.

Then again, I know people who think personal improvement should happen outside of work hours. shrug


If you're worried about being "slow", don't introspect, use metrics. First, define "slow". Everything else follows, so this is important. "x" many key strokes per hour? "x" solutions per hour? Since this part is so important, compare your definition to other's definitions. Then measure. Both yourself, and others with the same definition. Don't measure against others that are using a different definition, you'll be measuring different things.

Then, break the problem down into it's constituent parts. One possible breakdown: domain specific software engineering knowledge, technical coding ability, raw mental processing speed, decision making strategies and execution, mental focus, engagement.

Then, go back, define each of those, then measure, then start to hack the ish out of them. Deliberate study and practice can make up for a substantial lack of innate ability.

Also, consider that your hearts just not in it or that this particular line of work doesn't play to your natural strengths.

Supposing you're decidedly committed, realize someone will always be better than you, and worse than you. Find a place in your team where you best contribute to the overall teams needs rather than measuring your performance using a single dimensional metric, and be ready to be flexible should that need to change in the future. Maybe your slow, but maybe the fast person is fast in 9 out of 10 things, and super-slow in 1 thing, which you happen to be medium at. Well, the team is better off if you take care of that 1 thing. Everyone wins.

Finally, your health. This should be priority one. "Keep your shop, and your shop will keep you." You, are your shop. Take care of your shop. Regular and sufficient sleep cycles. Regular exercise. Regular social interaction. Regular mental stimulation. Daily mindfulness meditation. Not because you love yourself and you deserve it, but because this is how you keep your shop, the shop that pays your bills. Regarding pills, adderall actually fits the bill. But, the problem with pills is they are one dimension solutions. Adderall also reduces your ability to think creatively. Prozac increases brain plasticity. Armodafinil is an understated but highly effective smart pill. Guanfacine strengthens executive functions via actions in the prefrontal cortex. Selegiline is another legitimate smart pill, that you need to be super careful administering. Protein and omega fatty acids are super important, on an everyday basis. Intermittent caloric restriction is intellectually beneficial. Basically, define, break it down, measure, repeat. Always take the whole picture into consideration and always play the long game.


> "I have always been a slow programmer"

I'll try to make this post as short as I can, so forgive me if it seems abrupt. I'm going to take the opportunity to explore the possibility that you have no talent for programming. You should still take the advice to check out sleeping patterns, fitness, health, etc.

First, take a look at this website: http://the-programmers-stone.com/the-original-talks/day-1-th...

It's the first one I came across years ago on the subject of "What is the difference in the way of thinking between talented programmers and non-talented programmers). I don't think it is exactly right, but it's on the right track.

Lately, I've been experimenting with the idea that programming is a linguistic skill -- just like speaking. I spent 5 years teaching English as a foreign language and studying language acquisition. What I discovered was that students of English have the same kind of distribution of skill sets that programmers do: Some have a knack for fluency and can speak freely even if they have little vocabulary or grammar. At the other end, are people who literally can't order a drink from MacDonald's in English, but can tell you anything you would ever like to know about English. In programming, we often call these people "language lawyers" (it's a derogatory term, so I would avoid using it ;-) )

In foreign language teaching, there are 2 forms of ability: fluency and proficiency. Fluency means being able to listen to or read a sentence and automatically (with no undue thinking) understand its meaning. Similarly, when faced with a task of speaking, appropriate sentences pop into your head without thinking about it.

Proficiency is the range of language that you know. So it's the amount of vocabulary and grammar. Often someone with good proficiency will be able to puzzle out the meaning of a sentence, but it will take them a lot of time. Similarly, they can construct grammatically correct sentences by recalling all the rules and painstakingly piecing it together.

The old way of teaching was that building proficiency is the most important thing and that by repetition you would naturally create fluency. My experience has been that this is false.

By now, I hope you see some parallels with programming and people who experience problems with programming fluency. On the one hand, you have someone with a lot of knowledge (perhaps they have literally memorized the specs for a language and know every detail about the standard libraries), but are painfully slow. On the other, there are people who seem to be able to simply write code and guess how the language is supposed to work. They might not know details, but they can spew out code like nobody's business.

At this point, I will offer to exchange the word "talent" with "fluency". So I think that you simply lack fluency. Part of the reason you lack fluency is because people recommend largely the same unsuccessful strategies for becoming good at programming as they do for learning foreign languages (i.e., learn details about the language, class libraries, new languages, etc, etc.) In other words they recommend that you increase proficiency in the hopes that it will magically lead to fluency.

When you get a chance to read the Packers vs Mappers description in my first link, you might start to realize that this will not be successful. Mappers already think differently. They reason from first principles. They do not memorize rules -- they generate rules from the available data. Packers memorize rules and then search for appropriate rules to apply. If you are a Mapper, then learning proficiency will create fluency because you are adding more data from which to generate rules. If you are a Packer, you are just making your list of things to search longer and making your life more difficult.

As I said, the Mappers vs Packers analogy is useful, but flawed. I don't think that's actually how the brain works. Instead, I recommend reading about language acquisition, and in particular the work of Stephen Krashen. (Unfortunately, a comment is not the right place to discuss a topic of this size, but let me preface this by saying that Krashen's work is impressive, but that he is rather more confident about it than he should be based on the studies that have been conducted. However, it is the closest thing I have seen to something that will help you get the "pill for slowness").

Take a look at: https://en.wikipedia.org/wiki/Input_hypothesis

It's not the best description in my opinion. Krashen makes his book on the subject available online: http://www.sdkrashen.com/content/books/principles_and_practi... (I believe that's the one I'm looking for, but he has other resources available ad sdkrashen.com, so if you have boat loads of time, you can spend it reading his research ;-) )

So that's my theory. Now for practical advice. I'm afraid I don't have space/time to justify all the advice properly, but I will try my best.

- First and foremost is to start a large personal project and spend a little time every day on it (ideally 1 hour a day). More frequent updates are vastly more important than more time spent! The idea here is that at work, if you are slow, you spend a large amount of your time swimming in other people's thoughts. Because I assume that you are already proficient, the most important thing is to give you "comprehensible input" on a regular basis. It's not ideal (because it is your own output that will form the input), but working in an area where you have completely control, you will have less things to puzzle out.

- Throw out any notes that you might have that tell you how to do something (unless it is of the form "this is how you fix the server when it is on fire"). You need to be able to generate these things yourself on the fly in real time. If you have such notes (and I bet you do, because everyone I have ever seen that has your problem is almost buried in such notes), they are robbing you of the opportunity to repeatedly form understanding for how they are generated. You must form those understandings again and again and again or else you will not reach fluency.

- Every time you read code, you must understand it to at least 95%. It is hard to judge whether or not you understand it to 95%, so the rule is really, "you must understand 100% of everything you read". Many studies have found that when free reading, if the reader can understand 95% of the input, they can infer the other 5%. Less than that and you might think you understand, but you will be mistaken most often. This is massively important. If you think "I pretty much get this", "I think I understand what's going on here", "I've got a pretty good grasp of this, but don't understand some details" -- I'm going to suggest that you don't understand it well enough.

- To form understanding, the easiest way is to form a hypothesis and then test the hypothesis. If you have nice TDD code to work with, then it is easy. Look at the code, make some guesses about the code and then verify them with the tests. If you do not have such facilities, then you should still be thinking, "OK, if this method is here, then that means that there is an object X that calls it and sends the output to another method". Go and check.

- Occasionally, when you think you understand some code (say 20-50 lines), open up an editor and rewrite it without looking at it. This is expose the times when you think you understand what it is doing, but are wrong. I'm going to guess that when you first start this will happen more often than not.

-Read everybody else's changes to the system at work. Read every single line. Understand every single line. If you do not understand something, then get someone to explain it. Pair reviewing is a good way to have someone at hand to explain things. Comprehensible input is the only way to acquire ability. Writing your own code (output) is a secondary method (you are getting your own output as input). Read code every day.

- Time management... Sigh... this post is already massive, but this is super important, so I will try to explain it in as small space as I can...

Very likely, you have picked up "Packer" habits because it is easier than "Mapper" habits. Concentrating every minute of every day is hard. It's much easier to have a note, or memorize some formula and just whack it in without thinking about it. Over a lifetime, if you get into this habit, you end up not being able to build fluency because you are avoiding the hard work of understanding.

When you try to change that behaviour, your body will not be accustomed to it. Programming is a marathon, not a sprint. Not only that, but it is really a marathon. You can't stop to rest every 5 minutes. You have to tap out a rhythm for hours (sometimes expending more effort and sometimes less, but always engaged).

Just like you can't just go out and run a marathon, you won't be successful in staying focussed all day -- the whole day right away.

Some tips:

- Pair programming can help immensely. If you start drifting, you must ask for the keyboard, though.

- No social websites, news sites, distractions, etc, etc. No exceptions.

- If you do pomodoro, resist the urge to browse websites, talk about politics, etc, etc, in your rests. Keep a low level focus, while still recovering.

- Start with a 1 hour commitment. Take a rest and do another hour. Keep working at it until you can flow for 3-4 hours at a time.

- At the end of the day you should be mentally exhausted. If you are not, then you have allowed yourself to get distracted. Keep practicing.

Well, that's enough to get you started. Hopefully it will be helpful and you can use it to start an effective training program.


A lot of this rings true. Especially where you touched on following notes rather than deeply understanding a problem to the point where the solution can be generated by looking at the problem. I'm guilty of clinging to DDD-style application development and I don't even dare to think what my old code looked like before I discovered that.

Thank you for the in-depth links for more information.


OP, do you think you have problems following the logic within the code? Or is it like, i don't understand what the bigger picture is so I can't finish this task?


I think it's more that when faced with a code smell, I get into a mental loop where I evaluate each possible solution I can think of over and over without being able to commit to one. Sort of like a simulated annealing algorithm that never cools down.


Haha, I understand exactly what you mean. I used to be the same, I guess it never really goes away. I had a friend who was really quick, he knew as much as me and probably just as smart, the only difference is that he'd make calls and compromise quicker while I'd just ponder on the implications of each decision. It has a lot to do with out personality types I think. I have since learned to punt stuff and solve the problem I have, not problems I might have. It's good to be aware of the problems you might have in the future but trying to come up with a perfect solution will only lead you to produce nothing at the end of the day and frustrate you, like you have probably noticed. It's easier to fail fast and iterate, you learn from your mistakes. Also TDD helped a lot, Good luck!


Damn. Thankyou for making me feel better about my coding haha. Some interesting things to look up too.

That oacker vs mapper is interesting, id definatly fall into the mapper territory, although theres times id like a little more mapper!

Cheers!


Work on your health. Look for any hidden health issues. Getting a proper diagnosis and proper treatment can help you function better. Eat right. Exercise. Improve your sleep hygeine. Address any nutritional deficiencies.

"A sound mind in a sound body."


You just sound like you haven't been doing this a long time. "Fast" devs are either bad devs or they've been doing it a long time and are fast because they've seen a given problem before.


May not be helpful at all, but if you haven't done so in a while, get full blood work done by a doctor and see if you might be deficient in anything.


This sounds like a textbook imposter syndrome to me


It sounds like a broad topic. You may want to screencast short sessions of yourself coding, and then run them back to see what's taking longer. Here are some more thoughts:

1) Research: Do you find that you don't understand documentation of libraries, or don't understand what makes one library better than another when you're looking through your options (popular / common libraries)? I don't think this is necessarily indicative of slow cognitive skills. I think it's indicative of perhaps not asking the right questions when you go through the libraries to pick one in the first place. As soon as you start trying to decide for yourself whether you prefer one library over another or start seeing strengths / weaknesses in the libraries you do / do not choose, this is a sign you are probably starting to "get it".

2) Implementing the library: Do you read the documentation first? Or do you go straight to examples? Bypassing documentation is not always a good thing. Take the time up front to get familiar with what you're working with so you have a good overview and understand in general how one would perform tasks with the library and how the author intended it to be used. If documentation is sparse, look at the code. Is it a highly popular library and you're still having trouble understanding? If so it's not necessarily indicative of slow cognitive skills. Just spend more time reading others' code. By flexing that muscle (like with other mental exercises) it should improve with time.

3) Specifications. Does the company / client provide specifications? Or are you on your own and need to research the requirements of the project from scratch in order to assess what the project needs. Depending on the specifics and what the company / client's expectations are you may want to consider if cutting corners is appropriate. For example is this a Minimum Viable Product? If so cutting corners is probably ok as long as it meets requirements of the project. That's not necessarily a tip for improving but a practical point in that it's never useful to write code for a project that will never be used, so having a clear idea of requirements for the project is critical in order to know what can or cannot be left out of the implementation.

4) How often do you think abstractly about the problems you're trying to solve? Generally speaking in order to truly harness the power of programming and improve your speed to get common tasks done quickly, you should find ways to write layers of code just beneath your specific implementation to facilitate the implementation of common components (for example, an authentication system).

It's also sometimes a good idea to practice writing the entire component (if not for work then in spare time) from scratch. This way you will have gone through all the agony yourself and understand the real pain points in implementing components for a system and will be better equipped to choose libraries that truly help you to accomplish what you're trying to accomplish. If you've done this a number of times and still wouldn't be able to identify pain points or have ideas for how to abstract common tasks into libraries / classes of their own, then you may just not be thinking critically enough about the problems you're trying to solve.


Maybe the problem is you don't receive enough value for doing things quickly. For example, if you were paid $1 million to do a programming assignment quickly, you probably would.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: