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

61–70 of 118 posts

Re: Confessions of an Intermediate Programmer

#61

Post by adrusi »

akbar501 wrote: post #31
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.…

In my experience it's impossible to know what "pattern" to use where in real life code into you've made and realized the mistake that the pattern solves.

sitting down and learning a bunch of patterns and then using them without a deep understanding of why they are useful is misguided, and you'll end up with dogmatic code. not that it won't help, it's just not the most important step. the most important step is to write at least medium sized code bases without putting your ego into them so that you can be savvy to your mistakes.

Re: Confessions of an Intermediate Programmer

#62

Post by grey-area »

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…

You see a huge amount of this sort of poor-man's version control in other industries - everyone I have worked with in other industries has worked out some personal scheme of versioning using initials, dates, numbering in order to sequence the various states of their work as it passes through multiple people and multiple versions.

A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.

Re: Confessions of an Intermediate Programmer

#63

Post by swframe »

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.

The big thing I learned (at a company where all changes are code reviewed) is to rewrite the code until it seems obviously correct to someone who doesn't know what I know. I rename variables, methods and extract code into small methods until someone can read the code out loud and it sounds like a comment. for example: if (!thereIsEnoughSpace(user.getDataRequestSize()) { if (canAllocateAdditionalStorage()) { reserveStorageForUser(user, user.getDataRequestSize()); ...

I've found many bugs after I renamed variables like 'i', 'j', 'k', etc to something more meaningful. That made it easier to realized I was using them incorrectly.

This is basically why I think I'm an ok developer...

I pretend to be the smartest developer in my group (let's call him Bob). I look at a line of code and ask myself, why will Bob ask me the change this line of code? What will he prevent me from checking in? How would he solve this problem?

I do this even if I have a really difficult problem and Bob is the "go to" person. I pretend to be Bob and ask myself, What question will Bob ask me when I tell him about the problem? He will ask me if I've searched google, ok I will search first. He will ask me if I've checked for an upgrade to a library, I will do that. He will ask if I've set a break point here and checked for a memory corruption there. etc. 80% of the time, I find the problem myself and the rest of the time, Bob doesn't know the answer either. But at the end of the day co-workers are fooled into thinking that I'm as good as he is. But I have no doubt that Bob is better because it is important to him to learn everything he can about some key technology. I only approximate Bob when I need to interact with others. If you ask Bob a question, you get a quick and correct response. If you ask me, I will tell you I'm in the middle of something else and I will get back to you in a few minutes but really I have to figure out the answer first hahaha. I try my best to avoid getting help from Bob because, honestly, I don't think Bob respects people who aren't as passionate as he is (most people confuse passion with intelligence). The downside, is that it takes me a day to solve a problem that Bob can solve in a few minutes. Managers hate that but it is just too boring to learn technology to the degree that Bob knows it in my free time.

Re: Confessions of an Intermediate Programmer

#64

Post by illumen »

swframe wrote: post #63
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.

The big thing I learned (at a company where all changes are code reviewed) is to rewrite the code until it seems obviously correct to someone who doesn't know what I know. I rename variables, methods and extract code into small methods until someone can read the code out loud and it sounds like a comment. for example: if (!thereIsEnoughSpace(user.getDataRequestSize()) { if (canAllocateAdditionalStorage()) { reserveSt…

Both good comments :)

Another couple of ways to improve your coding...

Start with comments outlining what you're going to do. If you are pair programming, this shows the other person what your overall plan is. It also acts as a mini todo list. They should be "What comments". That is, what does this piece of code do, not how it should be done. Comments are better than just coding because you can do that quickly as a sketch to show your partner. Then they don't just sit there waiting for you to type out a lot of the algorithm.

You can also start doing this with tests first, which help you outline the interface for your object/method/function/module. This also helps you think about how easy your piece of code is to use by users of your code. ALotOf. ProgrammersDoNotThinkHowEasyYourFunctionIsToCall(x,a,3). Is it obvious what it does, and what the required arguments are for the caller? Is error handling sane for the caller?

Coding considering Revision control is very important, and these days acts like great documentation. With tools like git blame, you can see comments for pieces of code inside the revision control system. If you limit commits to nice small chunks on one topic at a time this is very helpful for people. Don't include white space fixes with 5 days of changes to 30 files at once, with a comment like "update". If they are nicely explained by the revision control comments, and perhaps even reference your issue tracker, then other people reviewing, reading, or bug fixing your code later will have a much easier time.

Finally, know when you are in prototype mode, pitch/demo mode, quick script mode, or Serious engineering mode. Each call for different approaches, and have different requirements. Don't let the Serious engineer get you to do a 10 day development cycle when you have a time limit of 1 day to deliver. That's a fail. Also, it's a fail if you hack something up without following all the development guidelines for some embedded life critical piece of software.

Re: Confessions of an Intermediate Programmer

#65

Post by dasil003 »

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…

Another part of it is simply being good at automated testing. For me this was the biggest point of TDD—to force myself to learn to test anything and everything. At the end of the day all code must be tested, it's just a question of whether you are doing it manually or not. For one-off scripts and such manual testing is the sensible way to go, but for long-lived codes tests are an investment. Of course the value and necessity of tests varies quite a bit by language as well.

Re: Confessions of an Intermediate Programmer

#66

Post by runiq »

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…

To be fair, though, once you get the hang of it, you have to take care not to apply it to everything. Back when I grokked Mercurial (first VCS for me), I used it for packaging scripts, dotfiles, /etc files, todo lists, shopping lists for the grocery store, financial accounting, and my own poor man's dropbox clone (please don't ask).

"When you have a ham^H^H^HVCS, everything looks like a programming project".

Re: Confessions of an Intermediate Programmer

#67

Post by runiq »

Bahamut wrote: post #4

I've actually been down this route when I was a kid experimenting with making programs. I did not understand what was the point of functions - why not just copy/paste blocks of logic? It wasn't something important to me for a long time since I did other stuff instead, but coming back to programming in an effort to make a career out of it, a lot of that stuff became instantly obvious & I felt foolish for not recognizi…

This sounds like the mammoth version of "sleeping on it", which has worked remarkably well for me.

Re: Confessions of an Intermediate Programmer

#69

Post by ZenoArrow »

angersock wrote: post #52
joeld42 wrote: post #18

Earlier quoted context omitted.

write more code. regret it.

Programming is 80% debugging, 20% writing bugs, and 1% off-by-one errors.

It amazes me that despite all the efforts made to improve programming languages, the debugging tools we're using are so clunky. I really wish more effort was made to improve them.

Re: Confessions of an Intermediate Programmer

#70

Post by dsego »

Code Complete is really great. I also recommend Clean Code. I started reading it before going to sleep, and it got me so excited I couldn't sleep. It was 4 or 5am when I finished it. All I could think about was refactoring all the code I had ever written.
Post reply on HN