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'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.
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.
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.
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 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 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.
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 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.
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.
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.
Diagnosing humans is pretty damn hard and will take time. Stick with finding a solution.
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.
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.
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.
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!
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.
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.
I think you're beating yourself up too much. A lot of good programmers feel the same way.  If you haven't done something before, it's going to take longer. 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.  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
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.
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.
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).
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":
Stick with it. The set-up is long, but it pays off handsomely.
The stimulant did the trick. I got my life back. Talk to your doctor and talk to a psychologist or neuropsychologist.
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
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'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.
- 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.
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!
"A sound mind in a sound body."
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.