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:
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.
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":
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.
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.
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.
"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.
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.
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.
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 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.
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.
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.
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.
>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.
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.
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.
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%
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.
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.
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...
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!
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.
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.
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]
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.
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.
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.
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.
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.
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.
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.
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.
72 comments
[ 3.0 ms ] story [ 133 ms ] threadI'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.
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).
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.
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.
Diagnosing humans is pretty damn hard and will take time. Stick with finding a solution.
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.
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.
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.
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.
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.
Check out: http://www.amazon.com/The-Motivation-Hacker-Nick-Winter-eboo...
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.
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.
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.
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.
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 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.
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.
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.
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...
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...
Thank you for the in-depth links for more information.
That oacker vs mapper is interesting, id definatly fall into the mapper territory, although theres times id like a little more mapper!
Cheers!
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.
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]
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.
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.
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.
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.
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.