undefined | Better HN

0 pointsxaa11y ago0 comments

Having gone through this stage myself and now mentoring others going through the same thing, I think it is an inevitable part of learning to code. A few pieces of advice:

- 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?

0 comments

3 comments · 1 top-level

hoboon11y ago· 2 in thread

Thanks for your advice. I do code on the side. I have a github and some OSS patches I've put in. Feedback from interviewers regarding it is that it is all amateurish and not so great/clean/beautiful.

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.

xaaOP11y ago

OK, then I misjudged your situation a bit, and in this case, your problem is likely not the code side of things, but the communication side.

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".

hoboon11y ago

this is very helpful advice. i thank you for it.

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.

1 more reply

j / k navigate · click thread line to collapse