Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Confessions of an Intermediate Programmer

michaelbromley.co.uk

Post reply on HN
Print view View original

31–40 of 118 posts

Re: Confessions of an Intermediate Programmer

#31

Post by akbar501 »

ritchiea wrote: post #16

What are the best ways to get better?

I think the following is a reasonable path:

1. Read more books. Turn off Twitter, FB, whatever, and open your Kindle app. But be picky. Don't read crap.

2. Read every day. 30 minutes minimum at the same time every day.

3. Write code that implements what you learn.

4. Write code that is more consistent. Learn to write in patterns. Use patterns that you both learn from a.) books, b.) reading other people's code, and c.) that you come up with on your own.

5. Program by using coding standards. Either your own, or if you're in a company then follow the team's standards.

6. Review what you've written. Identify alternatives to the patterns you've used. How else can feature x be implemented? What do you like about each approach? What do the experts say about each approach. Then read everything you can about various approaches to a given problem and implement as many of them as you have time for.

7. Read some code written by someone way beyond your skill level in a language you know. Take in how well they write. Pick one thing they did well, read about it, understand it, then integrate it into your coding.

8. Rewrite something you wrote at least a year ago. Can you easily find a better way to implement this code? If yes, then rewrite. If not, then read more.

9. Learn one new tool that helps improve your workflow and get to a point of daily use.

10. Speed up. Use automation to eliminate the basic coding that you already know well and that is now wasting your time. Use whatever is easy for you whether its templates, macros, boilerplate, generators or automation. Just pick one and automate away the stuff you've already learned.

Repeat.

Re: Confessions of an Intermediate Programmer

#32

Post by esonderegger »

sdrothrock wrote: post #3
csense wrote: post #2

AFAIK this is actually normal -- you learn the basics from tutorials, then the things that you need to make more complicated projects easier seem unnecessary, then you attempt a large project without them, and then you see why they're necessary.

It's normal but can be really, really scary if you don't have a mentor or someone to help you out or point out some of the pitfalls on the way. Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you…

What's worked for you all for making the leap from lone programmer to working on a team with a mentor/people who are smarter than you?

I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm writing something, it's always tricky figuring out exactly what it is I should be testing. When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this.

When you are good enough to make your own projects work the way you want them to work, but not good enough to contribute to the open source projects you actually use, how do you break out of your bad habits that you know you will need to break when part of a team/large project?

Re: Confessions of an Intermediate Programmer

#33

Post by krapp »

lstamour wrote: post #24
doktrin wrote: post #7

Earlier quoted context omitted.

My code changed in a similar way, however I recently devolved. I've mostly worked with higher level languages, and recently delved back into C. I had forgotten what a complete pain in the ass it is to pass complex data structures around between functions. I'm a bit ashamed to admit my functions got pretty damn beefy real quick.

Try C++, join the dark side! In addition to chocolate chip cookies, we promise C++11 move semantics for returned objects/values. The cookies/cake might be a lie. :-)

I had to create a small ADO class for advanced C++ last year.

It was... terrifying.

Re: Confessions of an Intermediate Programmer

#34

Post by farinasa »

lugg wrote: post #28
encoderer wrote: post #13

Earlier quoted context omitted.

The bit of leaked PHP code I saw seemed to be reasonably structured? Now, I wouldn't necessarily use PHP for this sort of work, but...

I hope you're not referring to http://pastebin.com/W8B3CGiN Those 100 line functions wouldn't make it through any half decent code review. Zero modularization, dal is inextricably linked to almost every piece of logic in the thing. Its an object called "Bitcoin" and I have a feeling it is 95% of mt gox' business logic if not all of it, it even writes raw xml to a temp pointer before dumping it into a cache and then m…

I personally like the hard coded values and the extremely long line lengths.

Re: Confessions of an Intermediate Programmer

#35

Post by brianpgordon »

ameister14 wrote: post #14

For me the thing I had to learn was commenting more than anything else; working alone I never saw as much use for it. Then I worked with a guy that commented his code very well and suddenly I saw massive value in it. I'm definitely still an intermediate programmer, but I think I was always fine admitting that to myself. It was getting over the fear of others reading and modifying my code that took me a while.

I had the opposite experience; I found it easy to scan through comments explaining what the code does, and hard to read the code itself. So I would comment every single thing to explain it in English so that I didn't have to resort to code. Of course I could drop into code mode and rely on logical axioms and learned patterns, but it wasn't as intellectually satisfying as "getting it" with pure intuition.

Something similar still serves me well as a general mental framework for approaching programming and debugging at a very local (procedure) level:

1. Make sure that the English language description of the algorithm is logically correct.

2. Make sure the code actually corresponds to the English description.

Re: Confessions of an Intermediate Programmer

#36

Post by gedrap »

From both my own experience and witnessing others, one major factor that sets apart from beginner and expert is working with legacy code. And by legacy I mean legacy from previous developer, previous team, whatever, not necessarily a decade old code base.

Beginners are keen to get rid of all the legacy code. It's tightly coupled, it's hard to read, hard to maintain, yada yada yada. And then they tend to make a way too optimistic estimate on how long it will take. While it might look like nothing fancy from outside, under the hood it often handles loads of edge cases etc. Been there, almost done that (didn't fit in the budget which was way too optimistic already). Eh.

Experienced programmers understand that it's not perfect, but they just live with that. Surely there are some cases when maintaining the codebase would be waste of money because the previous coder was a disaster, and sooner or later it will have to be scrapped away. But it's more tempting to do that than actually needed.

Re: Confessions of an Intermediate Programmer

#37

Post by stephencanon »

saganus wrote: post #26
derekp7 wrote: post #9

Earlier quoted context omitted.

Version control is one of those areas that is very difficult for a lone programmer to understand the need for (I was one). After all, I have backups, right? So why would I need it? Then I hit a snag, where something that worked before somehow didn't work now. And it was a lot harder tracking that down by going through backups, vs doing a git bisect and git revert. Eventually I ended up restoring every backup, and che…

Same here regarding version control.. until one day I after graduating from college I nostalgically searched for my old college files... and... oh the horror... my files where somewhere between "project1.final_backup_almost_final.java" and "project15.final_not_working.java.backup3" going through more strange things which I can't even think of why I named files like that, along the lines of "epsiloneridani43.final_wor…

O to be young and innocent of version control.

Re: Confessions of an Intermediate Programmer

#39

Post by mason55 »

esonderegger wrote: post #32
sdrothrock wrote: post #3

Earlier quoted context omitted.

It's normal but can be really, really scary if you don't have a mentor or someone to help you out or point out some of the pitfalls on the way. Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you…

What's worked for you all for making the leap from lone programmer to working on a team with a mentor/people who are smarter than you? I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm…

> When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this.

If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your total number of features will go down but quality will go up.

Re: Confessions of an Intermediate Programmer

#40

Post by esonderegger »

mason55 wrote: post #39
esonderegger wrote: post #32

Earlier quoted context omitted.

What's worked for you all for making the leap from lone programmer to working on a team with a mentor/people who are smarter than you? I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm…

> When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this. If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your…

I'm sure I'm not the only one who got down the road to overscoped features by saying "gee, wouldn't it be cool if my users could access this info that's living in a mysql table" and threw something together with a little php mysql_query(SELECT...), and it worked! except for some edge cases with non-ascii characters and the fact that you knew you were opening yourself up to SQL injection attacks, but you weren't really concerned because you only have 100 users and they're already authenticated by a more robust system. Anyway, you decide to do it the "right way" and rewrite it using SQLAlchemy. In the mean time, your coworkers wonder why you've burned half a day rewriting a feature that worked just fine after you had only been spending 30 minutes on it.

Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.

Post reply on HN