> Embrace the suck of your underachievement and get busy learning to master your craft.
That's what I'm asking. How do people get good at this? I figure it's practice and acting on things I can control but I don't know what I don't know.
That's what I'm asking. How do people get good at this? I figure it's practice and acting on things I can control but I don't know what I don't know.
- The first key is to keep trying -- it WILL get easier and become second nature. Problems that once challenged you will become trivial as you develop a personal bag of tricks and reusable code, and generally "level up".
- Become opinionated -- decide for yourself what programming languages/paradigms/methods will solve problems the quickest (and correctly), because that's what bosses care about. Maintainability and "best practices" CAN be important, but it depends on the exact industry and type of code you're writing. Each paradigm has something to offer, but not all paradigms fit all programming styles. You will need to try several different languages to achieve this. I would venture that it is almost impossible to be a good programmer without writing a substantial program in at least a half-dozen languages.
- Find a mentor. Ask them how they think you should proceed when you get stuck, ask them about what aspects of your code need improvement, and listen. If it is your boss, and they have the programming expertise, they will almost certainly be glad to help, because it will make you more productive. Otherwise, a friendly and experienced coworker.
- Code on the side. Lots of people want to work 9-5, but you will unfortunately not be competitive in this field if you do. Pick side projects that are fun and challenging. Volunteer patches on a OSS project, or find a nonprofit to do (challenging and interesting, not "can you build our website?") work for. If you want to, these side projects can also be for your job, but don't feel obligated to do this.
- Build a personal library of reusable code and algorithms suitable for your field. For example, mine is bioinformatics, and I have amassed over the years a toolbox of scripts and algorithms in various languages. I can then string together my code to solve a problem in one line of bash that would be hundreds of LOC if developed de novo. Put a lot of effort into documenting and generalizing this library (but also don't re-invent the wheel, use external packages when they exist).
- Familiarize yourself with critical relevant libraries in your field and language of choice. For example, in Python, this could be numpy, pandas, scikit-learn -- packages that have broad applicability. If you need statistics or linear algebra, learn it (for me, the best way to learn these abstract subjects is by using them -- implementing a statistics method or linear algebra-based algorithm by reading a paper and translating the equations into code).
EDIT: one final point that is very important:
- Realize that the purpose of programming is to solve a problem, NOT to write code. If you can find a simple way to solve a pain point for your boss or stakeholder, that is far better than writing hundreds of LOC. Sometimes this can even take the form of explaining to them why a certain feature they have requested is actually a bad idea. Somewhere along the hierarchy above you, there is a person who does not know how to code, and only cares about results. Always be asking yourself: how do I make this person happy with a minimum of effort?
Usually people don't look at it, though. People usually don't read my resume until they're at the desk, which seems to be common. I've hidden .gifs in the README.md files so they get triggered when someone loads. Though, the way github works specifically is that it loads it into a cache some where onto ec2 so I don't know who is looking at what; I just know someone is looking, and possibly others, too.
I do like python and am familiar with pandas/numpy/scikit (although all three are kind of more appropriate for experimentation than finished products).
> Realize that the purpose of programming is to solve a problem, NOT to write code.
I mentioned this to someone else: during an interview, code is all I have. I do take too long to solve some problems but I do solve them. I usually trip up translating them into code.
I remember one time I wanted to make a way to have JIRA automatically know what fix version goes into a bug but my boss said don't waste time on it. One of his complaints was that I would get fix versions wrong. I'm starting to wonder if maybe I didn't have a good boss.
One thing is that you are obviously down on yourself. That is self-defeating and self-reinforcing, because if you are unconfident, people will also assume that there's a reason, and most likely the reason is that you are incompetent. It's not fair, but it's true, and it's very easy for people to sense if you're not confident. This is independent of whether you actually ARE competent or not.
Also, if someone says or implies that you aren't competent (as it sounds like your boss did), that does not mean they're right. YOU are in the best position to know your strengths and weaknesses, and rather than telling yourself "I'm not good at this, I should take a job in tech support", you should be asking yourself, "how do I get (even) better?". Which you have, in this post, and that's a great start. It helps to remember how far you've come since you started. If a boss repeatedly treats you as if you were incompetent, it's time to find a new one. A good boss will be helping you get better, always challenging you but not throwing you in over your head, and giving you a good deal of independence. I myself would prefer independence, challenge, and feeling valued at the expense of a less shiny title or even a pay cut, but that's a personal choice.
Secondly, people do not make hiring decisions solely or perhaps even primarily on technical skill. In my experience, they want a candidate who has a certain skill threshold, and above that, they weigh other factors. Those factors typically include: how well do they fit in with the team, how self-directed are they, how well can they communicate to find what the real problems are, and can they solve them. So, in an interview, unless the interviewer is an idiot, you will get more "points" for clearly showing that you know HOW to solve the problem rather than showing you can write a syntactically correct program on the spot on the whiteboard. Again, communication.
I would be remiss if I didn't add that it helps a lot as an applicant to know or be known by someone at the company. That is the real purpose of using GitHub as a resume: not so you can say, here, look at a sample of my code, but so that someone you're interviewing with might say: "OH, you're the author of the widely-used XYZ library? Well, we can just skip the formalities and start discussing salary." I can almost guarantee that if one of your repos has a few hundred stars, you will not get any negative comments about your coding style.
Finally, your referencing Python as a prototyping language and mention of JIRA make me strongly suspect that you're at a BigCorp. BigCorps are, in my opinion, not a good place to learn, grow, and get independence. You will be treated as a replaceable cog. I would apply at a place where I could find a niche, master it, and be valued, rather than be viewed as "bug fixer #1057".
I think I might be below your threshold, though.
I agree with you about a great github. though i don't know what i could make that people would want in the dozens or hundreds.
my quip about python was more about np/pd/scikit. python is great.
i'm distantly aware that i'm whining. the past couple of months have been bad. in the past week i think i may have had a solid psychotic break.
No. At least for a huge fraction of the available jobs. What you have said, plus the very fact you are on this site, makes this almost certain. You need to realize what "incompetence" really looks like, and how bad many developers really are. I'm talking "copy and paste code from StackOverflow", "take 3 weeks to parse a simple file format", "how do I load a MySQL dump" level of incompetence. I have seen all these things.
> i don't know what i could make that people would want in the dozens or hundreds.
Make something that scratches an itch you have, that nothing else (good) exists to solve, then generalize it and write clear documentation so it will be useful to others. A hint: the main factors I use before deciding whether to bother with a GitHub codebase are: 1) the quality of documentation and 2) the frequency of updates. These two things indicate that someone cares about the code and is likely to continue supporting it. Think of this as a test of your ability to identify and solve important problems. It is far from necessary to have a popular codebase to get a good job, but if you do, you will have no problems at all.
> i'm distantly aware that i'm whining. the past couple of months have been bad. in the past week i think i may have had a solid psychotic break.
Consider seeing a psychiatrist (not a regular MD) who specializes in depression and/or adult ADHD. My work improved significantly when I was diagnosed with mild depression and ADHD and was medicated for it. This will not be a panacea: you will have the same problems, but will be better equipped to cope with them. IANAMD, but it seems quite unlikely you are actually psychotic. However, deep depression combined with a bad life situation can combine to make your mind do very strange things.
Realize that you are not alone, this happens to many people, and instead of a negative feedback loop of depression and failure, you can get into a positive feedback loop of confidence and success. Your fortunes can change surprisingly quickly if you take the proper steps, and you are very much on the right track. The biggest problem with depression is that it makes it difficult to take steps to fix it, but you are tackling that.
A final word on dealing with psychiatrists, though, if you choose to go that route. Do research, decide what condition(s) you likely have, and then present the psychiatrist with the relevant facts to help guide them to the proper conclusion. Also, if you are having suicidal thoughts, I would not recommend you mention them. This has ended very badly for people I know. A psychiatrist would be horrified at this advice, but the fact is that psychiatrists are busy, and will jump to conclusions based on very little data unless you are informed and help them along.
EDIT: One final small thing. Keeping with the theme of communication, I would suggest that whenever you're writing anything -- an e-mail, a HN comment, whatever, you always use proper spelling, capitalization, punctuation, etc. (unless it's to close friends). Don't be a pedant, but these basics mark you as an intelligent person who considers their thoughts carefully. Notice how all the top HN commenters do this here, even though this isn't a formal venue. This isn't a coincidence: people will automatically give words more weight if they seem to come from someone who thought them through. Although proper grammar doesn't guarantee this, using informal grammar definitely makes a bad impression.