hacker news with inline top comments    .. more ..    16 Sep 2011 Ask
home   ask   best   7 years ago   
1
Ask HN: How to get good at math if you are too bad with math
6 points by throwaway2211  35 minutes ago   2 comments top 2
1
tgerhard 22 minutes ago 0 replies      
What are you interested in? How in depth are you willing to study? I'm basically in the same boat and recently out of the blue developed a passion for math. I found there are plenty of free books available online. Right now I'm studying combinatorics, but every so often I take a couple of Khan Academy classes on trig. You might also want to check out Project Euler that offers the chance to combine math and programming.
2
medinism 32 minutes ago 0 replies      
I would start with number theory and getting very good at managing numbers in your head. I bought a book "how to calculate quickly" to help me with that. MOst algebra and calculus problems could be solved quite easily by running approximations in your head that solve the equation at hand. I learned this method from prof Feynman in his famous book "you must be joking Mr Feynman"
2
Ask HN: Best todo list?
3 points by superfx  42 minutes ago   1 comment top
3
Is jailbreaking killing DropZap 2 with one star reviews in the App Store?
3 points by amichail  1 hour ago   3 comments top 2
1
covercash 40 minutes ago 1 reply      
I love playing the original when I have a few minutes to kill. I just downloaded DZ2 and I haven't experienced any freeze or crash issues in the 10 minutes I've been playing it (non-jailbroken 4.3.5). Could the recent reviews be iOS 5 beta users?
2
raffij 1 hour ago 0 replies      
Jailbreak 4.3.3 no problem on start or play for five minutes.
4
How I manage my Hacker News addiction
2 points by begriffs  35 minutes ago   discuss
5
Getting feedback for Android app from within the app
4 points by varun729  2 hours ago   discuss
6
Ask HN: python or ruby for REST API creation
2 points by buraksarica  1 hour ago   3 comments top 2
1
damoncali 23 minutes ago 0 replies      
I can't answer your question directly, but if you choose ruby, this book may be helpful:

http://www.amazon.com/Service-Oriented-Design-Rails-Addison-...

2
Omnipresent 42 minutes ago 1 reply      
You can keep scala among the contenders as well. Lift especially makes it easy to provide REST api's http://www.assembla.com/wiki/show/liftweb/REST_Web_Services
7
It's OK to use PostgreSQL as a message queue. Sometimes.
3 points by ryandotsmith  1 hour ago   discuss
9
Ask HN: What % of your job interviewees pass FizzBuzz type questions?
40 points by tomx  5 hours ago   91 comments top 27
1
patio11 3 hours ago 0 replies      
For folks who doubt the numbers people are quoting here: remember, if half the pool can't program to save their lives, guess which half of the pool will still be sending out job applications next week.

At a previous company where, for cultural reasons, lack of programming skill was not a barrier to being hired as a software engineer, approximately half of our software engineers could FizzBuzz. Of our outsourced coders, I'd put the number at one of the twenty I knew, and he would need extensive coaching to make it happen.

Some of these folks were at least moderately productive at tasks which you and I do every day which theoretically happen in an IDE but do not require much abstract thinking, such as changing labels on UI elements, adding new columns to tables (by copy/pasting a line which worked and tweaking it until output matched expectations), and the like.

2
pixeloution 4 hours ago 4 replies      
Just curious if you expect perfect code on a sheet of paper or give them an IDE and say go for it.

As I remember fizzbuzz (print numbers 1 thru x, then fizz if divisible by 3, buzz if divisible by 5, fizzbuzz if divisible by both)

I did it in a text editor in under a minute. Got two errors because I did it without thinking, fixed it, and had a working solution in 90 seconds. It's taking me longer to write this response.

I can't imagine anyone who writes code daily who couldn't get this right in under 5 minutes given a text editor and a way to run the code, but I could imagine plenty of people who trying to do it on a sheet of paper who would make goofs. And most of those would make good employees.

3
ericb 4 hours ago 3 replies      
In the actual interview, I find that most give up after spitting out some pseudocode. About 40% have reasonable psuedo code that makes me think they'd get there (but these half-answers don't give me enough confidence to give them a thumbs up).

Actual code that works (and running it from a terminal), we are seeing only about 15% tops maybe lower.

We have started sending a fizzbuzz-ish question, a relatively easy css question, and a word-problem about performance as pre-interview questions through recruiters. This has dropped our resume inflow dramatically and saved a lot of time, but that's depressing in a way.

We are looking for a Rails or PHP dev in waltham (near boston) currently without a lot of luck. The job has a lot of pros, but probably doesn't do itself justice on-paper.

4
elliottcarlson 3 hours ago 1 reply      
I have used various interview questions, including FizzBuzz, factorials and other questions, and I would say the success rate I saw was about 20%. My personal favorite question is to have someone write a shuffle function without using any built in randomization functions - however most people give up, and others can't follow simple directions and wrap their head around the problem. This particular question had more of a 5 to 10% success rate.
5
ajuc 2 hours ago 1 reply      
I have question to recruiters:

if job requires "Hibernate" and I've used hibernate in my previous job, but have never configured it from scratch, only tweaked some models, wrote some EJBQL queries - does this count as "knowing Hibernate"? I've also never used Hibernate annotations, becasue we use hbm files, and we have templates to make the, so I'd have problems writing such file from scratch.

Do you check knowledge of required libraries on the blackboard? Do you assume people should know all the corners of such libraries, or do knowing some things and wanting to learn more if it will be needed suffices?

I use at work jboss, hibernate, jbpm, and many other technologies that are often mentioned in job offers, but I don't feel I can say I know them - only the parts that I needed to do the job. Is this considered not enough?

6
buro9 3 hours ago 0 replies      
I think that the lower the percentage, the more you need to improve your screening prior to getting the candidate in. It's just wasting your time and theirs.

I would love to say that you can tell from a CV whether or not they could pass FizzBuzz, but it's not true. I've interviewed MScs and PhDs that could not do FizzBuzz. Seriously.

The phone screener is your friend.

7
cantastoria 4 hours ago 4 replies      
I'm curious what candidates are getting stuck on. Is it the testing for divisibility that's tripping them up?
8
aplusbi 3 hours ago 1 reply      
I've never asked FizzBuzz but I do regularly ask coding/algorithm questions. They are usually more difficult than FizzBuzz. I'd say around 80-90% can at least come up with a solution in 45 minutes with some help. Probably less than 10% can come up with a good solution entirely on their own.

I attribute this to two things, first I think our phone screenings work well enough to keep out people who really can't do FizzBuzz, and second that I'm fairly generous during interviews. I often don't expect real code, sometimes I'm satisfied with just a discussion of the algorithm (no white board coding at all). I don't expect code to compile and I even let candidates use undefined "helper" functions (although I usually only allow that if I get the feeling that they could implement them if asked).

* For those that are curious I have two favorite questions - print out all the permutations of a given (ASCII) string and describe a search algorithm for a sorted array that has been split in two and the two pieces have been swapped (i.e. - 4,5,6,7,8,1,2,3).

9
corin_ 3 hours ago 2 replies      
Can anyone explain how it is possible for people applying for these jobs to fail?

I dabble in code, but am no where near the level I would have to be to do any job in this area, I mean seriously. Took my two minutes to do it with a pen and paper in PHP, same with in JS, same in bash scripting.

How can anyone who isn't able to do this pretend to even have an interest, yet alone the ability to do the job?

10
albedoa 3 hours ago 1 reply      
This post by Jeff Atwood might be of interest to you if you haven't read it:

http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

11
lrm242 4 hours ago 0 replies      
How are you asking the questions? Good interviewers try to adapt to the person they are interviewing. Depending on how you're asking the programming question, you might want to think about changing it. If, for example, you sit back in your chair and ask someone to go to a whiteboard to write code you should consider that some people simply are not going to respond to that sort of method of answering, even if they are a brilliant programmer.
12
chollida1 3 hours ago 0 replies      
I've actually asked this question as a gentle warm up for people, and we achieve around a 90% success rate.

On average it takes people around 5 minutes to do.

We have people do it on a whiteboard to get them standing up and moving.

13
eftpotrm 4 hours ago 1 reply      
That sort of thing specifically, never actually tested it.

The last test I did help administer was for a VB+SQL job, and the first question was to write an example of a valid INNER JOIN. I'd say at maximum 25% of the candidates could do this.

Improving SNR? I did once have a potential employer get me to do a time-limited online test. If you wanted you could always stick your questions into one of them, so you can at least do the fizzbuzz-level screening without calling them in and sitting them down.

14
DrJokepu 3 hours ago 0 replies      
In my experience, about one in five (20%) people I get to interview can solve basic programming problems on a whiteboard (in their language of choice). It's really depressing.
15
spamizbad 3 hours ago 2 replies      
4 candidates, 2 passed FizzBuzz. Oddly, the two that failed had a Masters in CS (albeit no BS in CS).

Of those that passed: one had Masters in Library Science looking to change careers. The other was a fresh out of college CS major from Illinois State.

Next batch, I think we'll add another trivial question: count the number of vowels (a, e, i, o, u) in a string.

16
ColinWright 3 hours ago 0 replies      
We now insist on resumes being accompanied by the answers to set "homework." No answers, no interview.

We get about half our interviewees unable to solve problems that are similar or easier during interview. Whether that's nerves/stress or simply an indication that they got someone else to do the homework for them we don't know.

One candidate even phoned a friend during the coding part of the interview to get some answers. For some jobs he'd be hired, but not for most.

17
acangiano 4 hours ago 0 replies      
I mostly interview students for hands-on internships. I'd say around 10-20%.
18
wpeterson 3 hours ago 0 replies      
The percentage of people who can complete a basic coding challenge during interview is more a testament to your phone screening than to the population of candidates.

If you're not weeding out these people with a 10-15 minute phone call you'll waste a lot of your and their time.

19
minikomi 4 hours ago 0 replies      
Wow.. This is pretty astonishing. I know this is a majorly skewed, opinionated audience, but do people really not have that much of an interest in what they do?
20
hga 4 hours ago 1 reply      
The last time I was a part of this activity in a company (1997-8), using similarly rigorous pre-screening, we had about the same results, only 50% of the people we interviewed could program their way out of an (EDIT) wet paper bag.
21
schulz 2 hours ago 0 replies      
I did a ton of interviewing a few years ago ~ 100 interviews.

I found about 10% nailed it right away with code that would compile and run. These were generally people who had been coding a lot recently.

Half of the rest (say 45% of total) got close: Minor syntax errors, logic errors, stuff that an IDE/non interview situation would have fixed.

45% just spaced. Couldn't right the for loops, conditionals. Couldn't write basic code.

22
davewasthere 3 hours ago 0 replies      
Of people who get to the interview stage, I'd say around %75 at least successfully do the FizzBuzz question on our test.

But we've cherry picked the CVs a little. And probably only interviewed 50 people over the past couple of years. (And hired 5)

23
mattdeboard 4 hours ago 1 reply      
I wish we would run at least some kind of sample problem before hiring people. sigh
24
mikereedell 3 hours ago 6 replies      
While we don't ask FizzBuzz in particular we have a question my manager asks: If you could fold a piece of paper 50 times, how tall would it be (very rough ballpark figure)?

Our success rate is surprisingly low.

25
gabyar 3 hours ago 0 replies      
About 80%. Perhaps we're more vigorous with resume screening. Over the last 4 years of interviewing, I've become very good at resume screening.
26
sungura 3 hours ago 0 replies      
I program a fair bit, have a few Android Apps in the market the problem I see with these type of tests is that I have a very hard time remembering syntax and would therefore have a hard time without an IDE.
27
EponymousCoward 4 hours ago 0 replies      
10-20% (pathetic really)
10
Ask HN: the "startup" look
3 points by coolpalm  4 hours ago   5 comments top 2
1
msencenb 28 minutes ago 1 reply      
Another great resource to get an MVP up and running is http://themeforest.net
2
randy99 3 hours ago 2 replies      
Have you thought about building first version with Bootstrap from twitter?
http://twitter.github.com/bootstrap/
11
Show HN: My midweek project - karmurl
18 points by lancashire  1 day ago   13 comments top 10
1
ashleyw 1 day ago 0 replies      
Love the idea, though: 1) email me when new feedback is received, 2) let me reply to people's feedback, and 3) preferably don't show me sites I've skipped, and definitely don't show me sites I've already given feedback to.

Good work!

2
iaskwhy 8 hours ago 0 replies      
Small request: a favicon!

I really like this idea, would use it a lot on the upcoming days.

3
patd 1 day ago 0 replies      
http://feedbackroulette.com already does something very similar.
4
mcrittenden 1 day ago 1 reply      
You might want to consider not showing a user a site that he/she has already reviewed (i.e., don't let me review the same site twice).

Great idea and nice simple execution, just reviewed a few sites!

5
illdave 1 day ago 1 reply      
Looks great - really good idea, thanks for making it.

Not sure if it's just me, but it doesn't display the full page when showing me someones site to review - it shows the top third and then just grey space (using the latest version of Chrome on a Mac).

6
saurabh 1 day ago 0 replies      
It seems perfect. It's small, usable and looks good. It would definitely would be useful for startups.
7
revorad 1 day ago 1 reply      
What a delightfully simple and useful app. I could use this all day long.

Thanks for making this.

Edit: I keep getting the test site asking me to skip. Maybe you should remove it?

8
Jasber 1 day ago 0 replies      
I'd e-mail users when new review is added. This way users know when to come back to the site and will make it more engaging.
9
drdoooom 1 day ago 0 replies      
Wonderful little app. I would actually spend some time going through it if I wasn't at work. Speaking of which, is there any process put in place to filter the sites people input?
10
mapster 1 day ago 0 replies      
Could you put 'how this site works' on the side, so I don't have to click on anything to get this info?
13
O'reilly *Free to Choose* - Save 50% on All Ebooks & Videos (code B2SDEAL)
10 points by nkassis  1 day ago   discuss
14
Ask HN: What issue tracker do you use?
4 points by imperialWicket  23 hours ago   2 comments top 2
1
saiko-chriskun 22 hours ago 0 replies      
Internally we use github (haven't tried many others, honestly, just integrates well and gets the job done.)

Publicly we use tenderapp. Always loved their design and UX flow.

2
edmarferreira 23 hours ago 0 replies      
We are using the github issue tracker. It's not powerful but is easy to use and free ( if you already using github for git hosting )
15
Ask HN: Is the jobs section broken?
11 points by dlevine  1 day ago   1 comment top
1
dbattaglia 1 day ago 0 replies      
It would be nice if the "who's hiring" posts for each month would show up there too.
16
Ask HN: What Eclipse plugins do you use?
5 points by daveoh  1 day ago   4 comments top 4
1
bostonvaulter2 1 day ago 0 replies      
We use the pmd plugin more on our jenkins build side.

Personally I've been looking for a good vim emulation plugin, I'm trying out Viable right now. There's also a plugin I used to use that would not let you use the menu for anything that has a shortcut key, that was nice for getting used to eclipse.

2
runT1ME 14 hours ago 0 replies      
VRapper is fantastic! And I use the Scala plugin, of course.
3
jaz 1 day ago 0 replies      
I'm using the Eclipse color theme plugin[1]. Changing the color theme from the default white to Zenburn made writing code for several hours easier on my eyes.

[1] http://marketplace.eclipse.org/content/eclipse-color-theme

4
teemrap 1 day ago 0 replies      
I haven't tried PMD yet but recently come across 'findBugs' plugin and it seems to solve my current purpose.
Other than that JavaDecompiler plugin sometimes comes in handy.
17
Show HN: Teledraw.com, a web-based drawing game
7 points by eggbrain  1 day ago   8 comments top 2
1
eggbrain 1 day ago 0 replies      
2
revorad 1 day ago 2 replies      
Oh please don't make me sign up. Just let me play?
19
Ask HN: Why do so many startups simply depend on FB alone, for the login?
8 points by vijayr  2 days ago   6 comments top 4
1
ig1 2 days ago 1 reply      
Because developer time is incredibly valuable to startups, the amount of users who don't want to use facebook/google/etc is relatively small so it's not worth spending the extra time to implement.

I think you underestimate the complexity of managing your own auth. It takes a lot longer than a couple of hours to do it right. Testing alone would take longer than that. Authentication is one of the most important part of many apps, it's not something you should be skimping on or doing in a hurry. It's much better to pass it off to a third-party until you have the time and resources to do it correctly.

(here's a bunch of things you might not have considered: password resets, https, stopping spam bots creating accounts, users changing email addresses, etc.)

2
arkitaip 2 days ago 0 replies      
The absurd part is that some developers believe that account creation is difficult/hard for users who are very sophisticated early adopters and privacy conscious.
3
harel 2 days ago 1 reply      
Auth, regardless of how long it takes should be built in your app, not farmed to 3rd parties. First fundamental building block of any app and its still, by far, NOT the most complicated part of any website. Farming out auth to facebook or Google should be an optional extra, not a mandatory process. I do have a Facebook account but I rarely want to link it to anything else. I'm still upset with StackOverflow for forcing me to use a Google account to log in as I use google Apps which are not yet deemed Google Accounts.
4
j_col 2 days ago 0 replies      
> It'll hardly take a couple of hours to write a simple login script, no?

Completely agree, makes sense to do the simple thing first, then optionally add auth from other services later. Given that I recently nuked my Facebook account for example, having Facebook-only auth on a site effectively blocks me and others like me from signing up (never a good thing).

20
Offer HN: UI Design for Hackers
4 points by niico  1 day ago   1 comment top
1
sidmitra 1 day ago 0 replies      
I'm working on a few apps. http://www.jobbrew.com is one, basically bookmarking(or lead mgmt) for freelancers.

Another one i'm also testing is an indie game marketplace.

PS: liked http://www.kiveve.com/

21
Ask HN: What do you expect from a coders profile site?
5 points by plunchete  2 days ago   7 comments top 3
1
jolan 1 day ago 1 reply      
> We don't just list your projects, we get the code and extract some meta data from them.

So you're cloning ohloh.com?

> as a coder what do you expect from a site like this?

Nothing really, github has done a nice job without even focusing on it.

2
ig1 1 day ago 1 reply      
It sounds like you're building a solution without having a problem. You need to decide what the problem is that you're tackling before you can build a solution.

Are you trying to build something that will let people quickly share what they're working on, are you building something that will act as a bio for people giving talks, are you building an alternative for a CV ?

3
ig1 1 day ago 0 replies      
22
Show HN: GAE/Bingo, A/Bingo split testing for App Engine & Khan Academy
8 points by kamens  2 days ago   discuss
23
Ask HN: Can you sell small non-scaling startups?
6 points by steilpass  2 days ago   5 comments top 3
1
danielh 2 days ago 1 reply      
Of course you can sell a small business, the question is at what price. If your potential for growth is limited, you won't get a Twitter-like valuation, but if your business is solid and profitable, someone might be willing to pay a couple times your earnings.
2
parallel 2 days ago 0 replies      
A company that has no growth potential is not very exciting to an investor. They 'make bets' on companies they think might take off. It's high risk high return as most small companies fail.

I think investor won't be interested in buying a business for small scale steady income. There are plenty of very safe ways to do that like bluechip shares or even term deposits.

3
eitland 2 days ago 1 reply      
Try "37 signals" first book, "Getting Real", freely available here: http://gettingreal.37signals.com/toc.php
27
Ask HN: I think My code isn't Good enough
136 points by mabid  13 days ago   91 comments top 53
1
nirvana 13 days ago 5 replies      
I know my code isn't good enough, and I've been programming for about 30 years! Not only that, my code isn't good enough, but I'm a great programmer.

I might be making some wrong assumptions, but I think the people whose code is really bad are the ones who think their code is good enough, or the ones who just code quickly without thinking. (I tend to think quite a bit and then code. In fact for the particular project I'm on right now, I'm doing a lot of thinking because I know the current architecture is not good enough. IT would be pointless to start writing code and then try to bash into shape- like building a stone bridge and then realizing you need a 57 chevy. No matter how much you take a hammer to that bridge it is never going to look like a 57 chevy.)

When I go back and look at code I did in the past, without having looked at it awhile, I see that it is really quite brilliant. I bet you'll see this in your code to. The thing is, the other person-- other's code, or your past code- is written when they have the full context of whats' being written in mind at the time they're writing it, and in the process of understanding their code you're going to see how their solution is more elegant than the naive solution you might have tried if you tried to write it just now.

Code takes thinking and refinement... and doing either will make code look better, and may be the source of your insecurity.

But, if your code really isn't "good enough", then maybe the issue is that your idea of "good enough" is too good. If its never going to be re-used, does it need to be reusable? If its not going to need constant maintenance, does it need to be beautiful? I have some code that I look at very, very rarely. Its in production, being used by customers every day, lots of customers. I know it is junk because at the time I wrote it, I was attempting to pull off a massive effort to get a product done. But the code isn't' throwing exceptions, it doesn't have bugs, and the customers are asking for new features, not fixes. So, I know its is ugly, I remember how ugly it was at the time, and every time I do have to go in I clean up bits and pieces of it. But it is working great... it is doing everything it should be.

And so, that code really shouldn't be good enough... because the time making it "good enough" is wasted time. If I wasn't the solo programmer on that project, then other programmers would likely work with me to clean it up... that's natural... but in startup land, sometimes ugly code that is solid is going to remain ugly code, because the point here is building a company.

Do you want a cathedral of very pretty code? Or do you want to build a startup?

I don't mean to denigrate your feelings... I think that your desire to improve is a good thing. I think the best thing you could do is to learn another language. (I'm just guessing that at 4-5 years you've probably really used one language a lot and 1-2 others a little bit.) Learning something radically different can improve you a lot. I'd recommend erlang (but I always recommend erlang.. it is the manly language that will make you a man (or woman))... or maybe you could use some scripting chops or whatever. Pick something out of your comfort zone, even if your'e going to be writing in your main language for a long time coming.

Knowing that other language will help you write better in your current language, and I think it will make you appreciate what you're writing in your current language better as well. I could be completely wrong here, but the best bang for the buck for me has been when I went outside my comfort zone and learned a very different language.

Finally, humans are bred, via natural selection, to have a certain amount of insecurity. We're supposed to fear that we're inadequate as it produces a wariness that helped keep us from being eaten by predators in the past.

Use it to keep you motivated to do better, but always make sure you're focusing on the right "Better". EG: IF you're in a startup, better is faster growth for the startup, not pretty code, though the latter can help the former.

Worse is when you worry too much about not being good enough and really end up not being good enough.

2
georgieporgie 13 days ago 3 replies      
Assuming you mean programming professionally (i.e. most of every day), then five years is around the point where you become self-aware and realize your code isn't as awesome as you thought. Also, remember that if you see code published on the Internet, it was probably extremely polished, and likely written by someone who has had quite a lot of experience in a particular area.

By having to maintain my code, I learned to write simple, concise, well-documented code. Nothing teaches you about bad programming practices better than having to maintain your own code after six months or a year away from it. I've also learned that iteration is key to quality. The first time I create something, it's basically crap. By about the third time I've tackled the same sort of problem, I have some pretty good insights, and come up with vastly improved solutions. Of course, people see the output of the 3rd iteration and think I'm a brilliant, insightful programmer, not realizing that -- like everyone -- it didn't happen on my first try.

3
fredleblanc 13 days ago 3 replies      
I felt like this with my code for the first 5 years that I was coding as well. My code now isn't pristine or perfect, but I'm consistently satisfied with the quality of my final products. Here's what I did to get to the point where I'm happy with my code:

1. Debug and refactor. Early on, I'd stumble through creating a script. It was usually write three lines, see if that worked, repeat. I didn't plan ahead enough, and by the end, my code was just layers of ideas tightly held together by a file name. This aggravated me, so after I'd get my scripts working, I'd completely rewrite them from scratch, making improvements where I saw them, simplifying code wherever I could.

I've learned more debugging (generally my own) code than I have from any book or teacher.

This was a lot of time spent, but eventually I could start seeing ahead and could make those changes in real-time as I was writing them. I'm not saying that I don't go back and refactor my code now, but when I do it's usually to fix things for speed or bugs, not for code cleanliness.

2. Plan ahead. I know some people that write out the entire shell of their program -- all of the functions and names and comments of what each function will do -- before ever writing the actual logic. I never had the patience for that, but you can still plan ahead.

Take a look at what you're trying to accomplish, and find the areas where you know you don't know what you're doing. Do a bit of research on those points. See what others have done, there's a really good chance you're not the first person to do those things. If you're still not sure, ask for help. The community is almost always willing to help.

3. Clarity over cleverness, always. I always take the road that will be more easily maintainable in the long run rather than the code that will work the fastest. (But, you know, if you can hit both at once, awesome.) I like breaking things down into simple bits. All of my functions are either only accomplishing one task, or are strings to those one-task functions put together to do something complex (but is still considered one task).

4. Learn, practice, learn, practice, repeat. Don't just stick with one language, branch out and see how other languages tackle similar problems. Take a look at code that you thin is better than yours and figure out why you think that. Take a look at code that's worse than yours and figure out why you think that. Write those things down and keep a list next to your monitor. Review them each time you sit down. Put them into practice. A lot.

5. Perspective. Take a look at your own work from 2-3 years ago and look at how far you've come. You've probably covered more distance than you think. Even if you're not 100% happy with where you're at, the progress will be reassuring.

6. Finally, stop worrying about it. Think of some people that are really good at what they do: professional athletes, professional plumbers, professional anything. When they're in the clutch moments, they're not stressing about how what they're doing looks, they're in "the zone," their mind lets go and instincts take over. Programmers develop those instincts too.

You're probably much better than you think, and you're only going to get better every time you program. :)

4
eneveu 12 days ago 2 replies      
I am passionate about writing good code, and I'll try to offer some practical advice. As others said, the first step is understanding the importance of writing clean code and taking pride in your craft. By doing this, you are already ahead of most other programmers who don't really care. Now, how do you improve?

1) Read books.

With 4-5 years of experience, you already have a good intuition for "good" and "bad" code. Still, it doesn't hurt to learn more about it. There are a lot of good books on this subject.

The first is "Clean Code", by Robert C. Martin. It's the first book I read on this subject, and I learned a lot. Note that the book uses Java in the examples, but I think the ideas would apply to most other languages.

Its author, Uncle Bob ( http://en.wikipedia.org/wiki/Robert_Cecil_Martin ) has long been a proponent of writing clean, beautiful code. He recently did an interview for Xebia: http://blog.xebia.fr/2011/05/25/interview-avec-robert-martin... (French blog, but the interview is in English). In it, he advises:

"Well there are a number of books that talk about writing code well. Kent Beck wrote a book called “Implementation Patterns” very recently. It's an excellent book all about software craftsmanship. The pragmatic programmers wrote a wonderful book in 2000 called “The pragmatic programmer”, again a wonderful book. Chad Fowler wrote a book call the “Passionate Programmer”. Again the book is about doing everything well. I wrote a book recently called “Clean Code” which is very specific about particular things you can do with your code to do it well. So there is a tremendous number of resources that are available for people who are interested in doing software craftsmanship well."

Out of those, disregard "The passionate Programmer". It's an okay book, but its focus is on building a good programmer career, not on code.

"Implementation Patterns" by Kent Beck is a great book with a lot of best practices when writing * Java * code. Less useful if you use another language.

"The pragmatic programmer" is a good book on software craftsmanship. I'm personally half-way through. There is a lot of good advice in it, but I often find myself thinking it's "common-sense". Maybe because I've already been exposed to most of the ideas by reading blogs? Still, it's a great book, with a lot of best practices. It's main focus is not code, though, so you might want to start with other books if your focus is on writing good code.

To these books, I'd add "Code Complete (2nd Edition)" (language-agnostic) and "Effective Java 2nd Edition" if you use Java.

Summary:

If you use Java, read:

  - Clean Code - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
- Effective Java 2nd Edition - http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683
- Implementation Patterns - http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091
- Code Complete / Pragmatic Programmer

If you use another language, read:

  - Clean Code - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
- Code Complete - http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
- Pragmatic Programmer - http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X

Other people might chime in with suggestions for other languages?

2) Practice.

Implement what you learned in the books. Keep improving.

3) Read other people's code.

Read good open source code. Not all code is good code. Ask around for OSS projects with good code in your language.

If you use Java, start with:

  - Google Guava - http://code.google.com/p/guava-libraries/
- Google Guice - http://code.google.com/p/google-guice/
- Spring Framework - http://www.springsource.org/

4) Practice.

5) Practice.

5
steve8918 13 days ago 2 replies      
First and foremost, write your code so that it can be understood easily by someone that knows nothing about it. As you get older, you'll realize that this person is you! Anything written over 2 weeks ago is often like looking at new code, so make sure you have good comments and non-obscure variable names so that you can understand it easily. This also makes it easier on your coworkers.

Second, write for readability and maintainability. Save optimizations for the last step. If your code is properly modularized (but not OVERLY-modularized) then you'll be able to selectively optimize and get good performance. As you grow as a programmer, you'll realize that having maintainable code (ie. code you can change easily with new features, or changing requirements, etc) with really good performance is far more valuable than terrible code with the fastest solution. Well-written code that is flexible and that you can shape like putty and add features to do what you want is exactly the point of programming.

The one thing you don't want to do is design code and products that become unmaintainable to the point where the costs of adding features becomes a nightmare. This is what I call coding yourself into a corner. I worked on a project where adding a single feature had a 3 page matrix of things that might break, and would need a lot of QA effort to validate. This is not maintainable code, and an example of where every new feature gets exponentially harder to add, which pretty much kills the product.

Third, I think it's great that you don't think your code is good. This means that you care! I would say only 40% of the coders I've come across actually cared about making their code better, or about mastering the art of programming. Just keep on programming, have a thick-skin to code reviews (I gave a code review to a new programmer who burst into tears because she had never been code-reviewed before), and be willing to learn. I have 15+ years of experience, and although I'm comfortable with my own style, I'm very open to criticism and always willing to learn.

6
icey 13 days ago 0 replies      
Ask people to look at it and give you feedback. There's a new Stack Exchange just for code reviews that you might want to check out:

http://codereview.stackexchange.com/

7
unoti 13 days ago 1 reply      
You do want to improve, but just relax and do your best work. Continue to learn and read other people's code that you respect. But don't let your desire to improve and impress others stress you out. Also, consider the rule of threes on reusability: http://www.rimmkaufman.com/rkgblog/2007/10/16/rule-of-three/

It seems possible you are being exposed to mentors that are being too harsh on you. Certainly you're being too harsh on yourself. Go forth boldly and code.

Take some time to read about _why's philosophy on coding and making mistakes. I think it would do you a world of good.

8
kgtm 13 days ago 1 reply      
You say you have been programming, but not if you are solely a programmer or building a product as well. Perhaps it would be easier to think of code as a medium to achieve a higher goal, which is functional software. I'm inclined to believe that this is more important than "code beauty" which is something highly subjective and tends to be constantly evolving with your experience.

Note I am not promoting spaghetti code. If it's not blatantly incomprehensible (i.e. you abide to some common sense) and works, you are set.

Of course this is my view after having spent non-trivial amounts of time making code beautiful, modular and reusable instead of trying to solve the problem at hand. YMMV.

9
nuclearsandwich 13 days ago 1 reply      
It's constant, almost everyone experiences it. Best thing to do is look at some really old code you wrote and realize how far you've come. After that, write more code, read more code, write more code. Programmers all want to be better, this drive helps us become so, but it also drastically diminishes our ability to be content with our current situation. If you really want to see how far you've come. Find someone who reminds you of yourself and mentor them. It's much easier to perceive change in others than change in ourselves. Watching mentees progress reminds you of when you underwent the very same realization and helps you become more aware of liminal points in your programming journey.
10
mnemonicsloth 13 days ago 1 reply      
If it solves the business problem your clients are paying you to help them with, your code is definitely good enough.

The people with opinions about your code are probably not paying you. So coding well is more like being polite to them. Really good code makes their lives slightly easier than average code (which is way better than no code).

But politeness goes both ways. If they see you trying to improve, they'll probably try to help you.

PS - When people want to get better at somthing, the biggest mistake they make is assuming they can get better inside their current comfort zone. So if you want to improve, get lost for a while. Try writing an OS. Or a physics engine. Or learn a Lisp. You'll be surprised how fast Experience - From - Elsewhere translates into more skill in your day job.

11
lawn 13 days ago 0 replies      
I wouldn't really think too much into it. I've had the "not good enough" feeling for years, in fact, ever since I started programming!

A few years ago I started working on a game, the best ever I thought. I was so clever with everything I thought and oh I wouldn't need to refactor because I would do it right from the start!

Of course I moved on and started to work on other things for a while and when I came back I thought it was horrible, almost unusable!

This happens all the time, though at a lesser extent, for me. When I notice something new, fresh, nice or beautiful way of doing things the old way is simple not good enough. Why did you ever do it that way?

Don't bother too much - it's normal and it shows that you're always evolving and getting better. And after all, you learn by doing mistakes not by doing everything beautiful and perfect from the start.

12
geraldalewis 12 days ago 0 replies      
> good code written by some one else

Exactly -- someone else. I don't have a formal Computer Science education. I'm juggling reading the K+R C book, Knuth's Literate Programming, Odersky's Programming Scala and the Ruby "pickaxe" book. All of them have been great. But their impact on my code and career all pale in comparison to the strides I've made by paying attention to the social side of programming.

You should now:

* Talk to other programmers. I found a couple groups on Meetup.com that I like attending. Sometimes they're not specifically about programming (like my UX meetup). That's good. I am cross-training. I have asked some programmers whose work I admire for beer/coffee, on me, and I've had some great experiences. You will hear new ideas, and will have to defend your opinions.

* Find an open source project you like on Github.com and start contributing. Start with easy #bugs in "Issues". If you don't know which ones are easy, ask. You will get invaluable peer review, sometimes from the best minds in our field. You will read great code, and you will modify it, and so you will understand it deeply. You will have the satisfaction of knowing your code is used by hundreds or thousands of people.

* Find beauty in other things.

13
RyanMcGreal 12 days ago 0 replies      
After a little over ten years of daily full-time coding, I'm finally at the point where I can go back to code I wrote three or six months ago and not think, WTF? I'm by no means a great programmer, certainly not compared to some of the brilliant coders on HN, with whose work I'm constantly inspired and humbled; but as Dirty Harry famously said, "A man's got to know his limitations," and I think I'm pretty realistic in that regard.

To get better: keep noticing your mistakes and taking them into account on subsequent activities; keep modifying your workflow to incorporate and automate good practices and to remove the potential for preventable mistakes; keep taking opportunities to clean and refactor old code when you have to face it; keep reading other people's code (especially those brilliant coders kicking around HN) and learning from it; and keep pushing yourself to get better. Rinse and repeat for as long as you spend programming.

14
igorgue 12 days ago 0 replies      
Disclaimer: I have like 6 years of experience, I'm not a famous programmer, but I do get people telling me (more than 20 programmers) that I'm a good programmer and I write good code.

Read code, watch people coding, care about your tools, and finally, your code will never be "good enough" you'll always improve.

Read code: Read open source software, from the libraries and frameworks you use for example; That way you'll learn new techniques and ways to organize your code so it's more readable. Also it helps reading books like Code Complete and Beautiful Code. I recommend "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" even though I'm not a .NET programmer I really like that book.

Watch other people coding: Get together with friends to pair program, or online, most people like to pair program. Or watch some of the new Peepcode videos on experts programming (https://peepcode.com/screencasts).

Care about your tools: Now that a lot of people are using dynamic languages I see it over and over again, people just use whatever editor, debugger, etc etc, care about those things, you'd rarely see myself making a "unused variable" mistake, because I have all the linting tools, and I follow them, same goes to code formatters, etc etc, I recommend VIM to edit code, Git as a communication tool (which is version control), Chrome as debugger. Also try the best way you can to reuse things, framework like Backbone, Batman, Knockout helps a lot with your JavaScript, never use just raw jQuery, it's not needed anymore.

You're never gonna be good enough, there's always gonna be a DHH, Jacob Kaplan Moss, Jeremy Ashkenas (just to name a few) to look up to.

15
mst 13 days ago 0 replies      
I gave a lightning talk some time back on this topic called "You aren't good enough" - video is here:

http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-...

Any time somebody says they feel like you do, I throw them a link; it seems to help.

16
stonemetal 12 days ago 0 replies      
I have never believed in beautiful code. That is like saying there is a beautiful spanner or crescent wrench. Save the beauty talk for the Rembrandt and Monet. I pursue two things in my code Clarity, relentless reliability and simplicity. Clarity because I am like the girl from 50 first dates I not going to remember it tomorrow so it better be clear enough that someone(me) will be able to figure it out without to much trouble.

Relentless simplicity, if making your software a little simpler to use means that its 1 million users have to remember 1 less thing because you have remembered 1 more thing then you have just saved 999,999 brain cells.

Relentless reliability is rather similar to relentless simplicity it should work the same way every time all the time. Any time you break the guaranty of getting it done right you just cost a lot of thought and effort for a large number of people.

17
watmough 13 days ago 0 replies      
Yeah, I feel like that almost all the time.

You have to write a LOT of code before it flows perfectly from the fingertips. That's the key, write lots of code and be aware how you can improve.

Here's a few points that have been useful to me:

1. Write code to be used. If it's not useful, why are you bothering? If it's useful, other people will use it and demand changes and complain about bugs.

2. Great programmers code fast. Write code quickly and refactor whenever necessary. Get miles under your wheels. Great racing drivers drive. Practice, practice, practice. ABC - Always Be Coding.

3. Practice refactoring. If you see a better way to do something, implement it. Don't cry that you're scared to change it because it's 'working'. ALL your code should work.

4. Set small targets that you can accomplish in an hour of so of designing or coding. Always have a pile of these ready to work on. Work on them when you have an hour free. Code fast, test and commit.

5. Use git. Commit at a fine granularity so you can see your enjoy your progress.

6. Always ask yourself "Is this code clear? Do I trust it?" when reading a source file.

7. Don't fight your tools. If you constantly edit auto-completed text, STOP DOING that and fix it or disable it, or learn to write idiomatic code.

Thanks for the question, and I hope these are useful. It's fun for me to crystallize some of this stuff!

18
leif 13 days ago 0 replies      
never be afraid of refactoring, but only do it when you're changing a piece of code anyway (otherwise you'll drive yourself nuts)

get others to review your code whenever possible. for that matter, do code reviews yourself whenever possible, it'll make you better at writing code too

always write it the simplest way you can, especially the first time. code that's clever for the sake of cleverness is bad code. learn about compiler optimizations, there are plenty of things compilers will do to make it so you can write clear code that is still fast, and there are plenty of clever things you can do that won't make an iota of difference in the end.

19
impendia 13 days ago 0 replies      
Congratulations!

You have healthy appreciation and respect for work better than your own, always a good sign, and it means you should expect to keep improving simply by keeping at it. Same is true in any field.

20
shawnz 13 days ago 1 reply      
Here's Jeff Atwood's take on it: http://www.codinghorror.com/blog/2009/07/nobody-hates-softwa...

"I think you can tell a competent software developer from an incompetent one with a single interview question: 'What's the worst code you've seen recently?' If their answer isn't immediately and without any hesitation [the] two words 'My own.' then you should end the interview immediately."

21
joshcrews 13 days ago 0 replies      
The two things that help me the most in this department are:

1) write tests first because then you can write something ugly that works and then refactor underneath passing test coverage

2) expose yourself to other peoples code. My tendency is to stare at my own stuff all day (or other people's unattractive code). A natural place to look at good code is to be quick to open up libraries you are using in a project and rummage through them as the need naturally comes up in your work

22
awwx 13 days ago 1 reply      
what you think I should do to improve on that

Rewrite.

Write some code, make sure it works, and then look at places where it's ugly and figure out how to rewrite it so that it's better.

You won't write good code the first time, unless you're writing something that's trivial for you (too easy).

While the examples are too Java specific, the book Refactoring by Martin Fowler is a terrific introduction to the skill of improving code.

23
mtkd 13 days ago 2 replies      
If you're using it for a start-up - it's much more important to deliver usable software than quality code - you can always go back and clean up the code - but if you don't get traction it's all over.

Also - consider buying code reviews from developers you respect - even a couple of hours a week can make significant difference to your quality.

24
noelwelsh 13 days ago 0 replies      
Thinking you aren't good enough is the first step to getting better. At the risk of sounding cliched, it's the journey not the destination that's important. You never arrive at perfection anyway, so I wouldn't worry!

The best thing I can suggest is expanding your horizon as far as possible. Your profile says you're a RoR/JS programmer. Go learn some Haskell (or any other functional language; I started with Racket) and you'll find a truly different way of looking at programming, one which will change your style forever.

25
jaekwon 12 days ago 0 replies      
there's an art to writing readable and reusable code, but you have to start by understanding the problem.

when you really understand the problem, the problem and surrounding use-cases become obvious. when this happens, writing readable code becomes trivial, as long as you understand what tools you need to use to solve it.

sometimes the right tool is a library, sometimes it's adapting existing code, and sometimes it's a special language construct like Python metaclasses.

whatever your problem, try to describe it and the solution in english at a high level. then, how can you best fit your solution into the mental framework that you just created?

as for reusable code, just be aware of leaky abstractions and complexity. often times i see libraries that introduce more complexity into a program than needed, sometimes because the solution doesn't really fit into a module. often times the solution is another language, like jQuery or Haml.

anyways.

26
cpeterso 13 days ago 1 reply      
I recommend settling down in your armchair by the fire with a good brandy ;) and reading code written by the masters. The Plan 9 code has some very clean code I'd love to hear others' recommended "classic" works..?

Conversely, ask other people to review your code. It's an opportunity to get feedback on your code, discover bugs, and earn brownie points flattering your reviewer. ;) You can read "The Humble Programmer" to prepare your ego for constructive criticism.

Also, dabbling in other programming languages can give you new perspective into your other work. Scheme and Haskell are good languages for waking up dormant brain cells. (I'm working through the "Learn You A Haskell" tutorial Noah

27
DanielRibeiro 13 days ago 1 reply      
Reusable code/efficient code is usually more complex and less readable. I find this is usually not a big issue, as I can always refactor change to the design I need later.

Just in time, not just in case.

28
bluedanieru 13 days ago 0 replies      
I think if you're shipping and it works, and you find you can revisit it in a few months without being completely lost, you're in pretty good shape.

I have the opposite problem where I'm generally happy with what I write, it works and is usually well-factored, but it seems to take me fucking forever to get it to that point. So count your blessings :-)

29
josephg 12 days ago 0 replies      
I've been programming for about 17 years and here's what I tell my students:

Every program has 2 goals: To explain to the computer what you want it to do, and to explain to people what you want the computer to do. Good code is readable and correct.

The first time you encounter a problem, your first idea of how to solve it will be awful. This is true no matter how long you spend thinking about it, no matter how much experience you have. The best workflow involves thinking, then coding, then thinking, then throwing away most of your code and doing it better. You can't find the flaws in an implementation while its in your head - you need to see it on the screen before you can fix it. Your second implementation will generally be better. The best code I've written I've iterated on 3-4 times until it looks simple and obvious.

Unit tests will help you iterate - write them before / just after your first attempt at the code. Then when you rewrite the code you'll have confidence that you haven't broken it.

You're not writing poetry. Sometimes your code is hard to read because you're doing a simple thing in a complex way. Other times your code is hard to read because its algorithmically complicated. In the second case, spreading the algorithm out over lots of places will make it almost impossible to understand. So, don't stress out when you can't make your code into a haiku. Sometimes you can't - but you should try anyway.

The best way to learn what good and bad code looks like is to read code. At first, reading code will be harder than writing it. You should do it anyway. Your own code is ok, but other people's code is better. Pick an opensource library you use and try and figure out how you would write it. Then read the code and see how they did it. Their method might be worse than yours. - But remember, their project is successful anyway.

30
usedtolurk 12 days ago 0 replies      
You're definitely not alone in feeling like this. "Good enough" always depends on the circumstances, so the best way to know if your feelings are warranted is to get honest code reviews from the people who will be working with your code. Balance that with external reviews from programmers you look up to (expecting some contradictions) - then take your own path.

Don't despair if you get a lot of negative feedback - it's easy to improve by reading some of the books listed in this thread and repeat.

Enjoy the journey - I've yet to meet I've yet to meet someone who's reached the destination (although plenty have stopped along the way).

31
bajsejohannes 12 days ago 0 replies      
Ira Glass talks about this: http://www.youtube.com/watch?v=BI23U7U2aUY

His recommendation boils down to keeping doing it until you code matches your expectations.

32
typicalrunt 13 days ago 0 replies      
Let's take programming out of the equation with a quote.

"Laws, like sausages, cease to inspire respect in proportion as we know how they are made." - John Godfrey Saxe.

The problem with looking at any recent code that you write is that you know how it was made (i.e.: you are in the kitchen making the sausages). But it's different if you are the customer eating the sausage. Even if the cook told you how the sausages were made, you still don't have first-hand knowledge, so you elide over the means (good or bad) to get to the ends. It's only when you really dig in and start to understand the process you start to see that the people making the same things you make are in the same boat as you.

33
chrismealy 12 days ago 0 replies      
4-5 years isn't that long really. I've been at it 20 years or so and there's never been a time when I wasn't slightly embarrassed by what I was doing just the year before. Programming is fun that way, you're always getting better.
34
thedjpetersen 13 days ago 0 replies      
Programming is a skill that one constantly improves at. The first step seems just to implement good practice into your code. Then it is learning a common way to problem solve.

The most important thing, something that I learned from a comment on this site(I can't find it at the moment), is to "just keep coding". Jump on an open source project. Take something small, find another programmer which you admire, and try to learn from their style.

Work with others. Pair programming is a great way to learn from someone else, it lets two people pick each others brains.

Remember becoming a good programmer is a journey. It is not something that achieved instantly.

35
lobo_tuerto 13 days ago 0 replies      
I recommend then you start taking tiny bits of software architecture to improve your code and your understanding of code structure. It can help with reuse, better practices, etc. For example get a copy of Ruby Design Patterns.

The things you will read about in it can open your eyes for better recognizing where you can improve your code, how ti apply _this_, how to solve _that_, and can give you ideas and new ways to look at structuring your code for better reuse.

Design patterns aren't an end on itself, but means write more modular, readable, understandable code.

36
billrobertson42 12 days ago 0 replies      
Just tonight I had to work on a code base that I initially wrote about five years ago. This is a working product that's been rock-solid for the client. Still though, at one point, I really hated the code.

Nevertheless, I've been able to extend bits and bobs of it over the years without major headache or breakage. And tonight I had to write a simple related utility program. I was able to grab various classes out of the code and just use them, or re-purpose them with little effort.

Are there issues with the code? Hell yes. I'm always learning as a programmer and I'm much better now than I was then. Does that mean the code was crap? It feels kind of hard to say this, but no it wasn't crap. It did the job and it hasn't been a maintenance nightmare.

So when you look at code you wrote 6 years/months/weeks/days/hours/minutes ago and think, that's total crap! Don't beat yourself up over it. It just means that #1 you care and #2 you have learned something between then and now.

Oh, and after looking at the first line of nirvana's post, I thought about it and realized I wrote my first bits of code about 30 years ago too.

37
michaelbuckbee 13 days ago 0 replies      
I think this more a life issue than a code one. In some ways if you're not looking at what you did a couple years ago and thinking "Wow, I would do that so much better now" then you aren't progressing.
38
wccrawford 12 days ago 0 replies      
If you think that, you're probably right. Figure out why, copy it. Over and over and over.

That's how you improve at every craft.

39
danbmil99 13 days ago 0 replies      
It's pretty natural to be disgusted by one's own code, except in very rare circumstances. Typically you like it when you've just written it (but before it's been transformed into garbage by real-world needs).
40
benologist 13 days ago 0 replies      
My code's crap and I feel sorry for the people I'm going to hire to take over it - and a little bit embarrassed - they will probably be better programmers than me and I will probably learn how to write less crap code from them.

But oh well. Shit happens, and my code got me this far.

41
erikb 12 days ago 0 replies      
Is a good programmer one who creates good code or one who is always looking to improve his code, experiment and get his programs to work?

Look with pride at the mistakes of your past and be ready to do more mistakes to improve in every line you write. That's my philosophy for now.

42
sleight42 12 days ago 0 replies      
- Read open source code of people whose code you respect
- Pair with those people.

Remote pairing is pretty easy these days with SSH, tmux, and VOIP.

43
yason 12 days ago 0 replies      
If your code begins to look good and other people's code begins to look bad, you know you're not in the right company.
44
TomGullen 13 days ago 0 replies      
If someone is paying you to do it then by definition it is good enough in my opinion. The idea of perfect code is very abstract and impossible to ever reach. Coding is a journey and about incremental improvements I think, always try and learn something every time you sit down or you will fall behind the pack!
45
yn 13 days ago 0 replies      
If you are programming in imperative languages, I think you can learn from Dijkstra and Gries.

In my own experience, mathematics is the only way to gain assurance.

46
otaku_coder 13 days ago 0 replies      
I think that nearly all good developers feel their code isn't "good enough", so its nothing to worry about! This search for perfection will drive you to constantly improve and practice, which can only be a good thing!

Keep coding, and as always ask the developer community for help and advice, stackoverflow has certainly helped me a lot.

47
BasDirks 13 days ago 0 replies      
I hope for you that you'll never think your code is good enough. Keep growing.
48
manishtomar 12 days ago 0 replies      
This proves that you are learning and there is still much to learn. I've been programming for 6 years and I feel it all the time. I think the only way to feel better is to keep writing better code by keep reading better code.
49
DiabloD3 12 days ago 0 replies      
I'm probably going to get down-voted for this, but it doesn't really matter if YOU think its good enough: it is a combination of "your competitor's code (ie, everybody on the Internet, not just in the realm of your business model) ISN'T good enough" and "does anyone else think its good enough".

Being highly self-critical of code is good, but don't let it stop you from writing absolute crap. Several people (of which includes Bill Gates) have sold/shipped absolute crap code and are now amazingly rich.

Whoever codes it wins, it usually doesn't end up who codes it better unless the original has serious flaws that were not corrected.

50
polemic 12 days ago 0 replies      
The only code that I've ever been happy with was module code I open sourced. It took a lot of time, use and feedback to get there. Hard to argue that it was really worth the time, except for my own pride.
51
hsmyers 13 days ago 0 replies      
Refactoring your code or yourself is not a terminal process.
52
alcuadrado 12 days ago 0 replies      
Start by reading Code Complete!

            a cleancode frantic

53
indi 13 days ago 0 replies      
my code is not good enough, when i need to make change, and i find it difficult. and this is when i need to refactor.
28
Ask HN: Our competitor scams their clients - what should we do?
7 points by vgurgov  3 days ago   7 comments top 6
1
jnorthrop 2 days ago 0 replies      
If you have evidence of fraud contact the FTC or the FBI. If they aren't committing a crime then let it go. You will not win any favors by bashing your competition.
2
ig1 3 days ago 0 replies      
How do you know who they're selling the premium product to ?

You need to be careful that you're not misunderstanding the situation, because if you go public and find out you're mistaken they could sue you out of existence for libel.

What you could do is present the data (say in the form of an industry analysis comparing the industry players) including case studies showing what their client are receiving and publish it.

You could then send it around to their clients (X is what you're receiving from Y, you could be receiving Z from us). And let the client make the deduction that they're being scammed and not getting what they paid for.

3
CantDecide 3 days ago 0 replies      
Apple can charge a premium for their equipment because they are known as a premium brand. Even if they could make their products for 1/3 the cost, they would still charge the same price because they need to be seen as premium products, and because they can.

If you are sure you're competitor is over charging, maybe it is for the same reason. As dandandan said, maybe you are pricing your product too low.

Going after them publicly, accusing them of scamming or unethical behavior will only backfire. Either your company will be branded crackpots and unreliable, or you will actually get negative press.

The best you can do is in your marketing and sales pitches, say "our prices aren't as inflated as our competition but our product is better than theirs." Then prove it with examples of product quality. Your customers will do their own pricing research.

4
dandandan 3 days ago 1 reply      
Overcharging customers who are willing to pay that rate isn't "scamming" them per se. It could be considered unethical though and will probably come back to bite them even without going to the media about it. Are you sure your rates for whatever you provide aren't too low?
5
vgurgov 3 days ago 0 replies      
Thanks for all the feedback. I guess i posted op in a hurry and my points were not clear.
1) Know for sure that they are misleading their clients. We know how this industry works very well and we collected all evidence.
2) Scam is like this. They are saying to clients that they will get bananas and charge charge them for bananas. Market price for bananas in this industry is 20-30 cents. In fact they are shipping them peanuts with price of 7 cents at most. In fact they are selling them very bad peanuts that cost even less and noone really wants them.
6
MattBearman 3 days ago 0 replies      
I think people maybe misunderstanding the original post (either that or I am).

My understanding is that their competitor offers 2 products, a basic and a premium (this is an example, I've no idea how many products their competitor offers).

The scam is that the people paying for the premium service are only getting basic. Ie, they would get exactly the same service if they were paying for the basic.

29
Ask HN: What to suggest to a 12 year old, who wants to learn App Development?
3 points by Brajeshwar  2 days ago   8 comments top 6
1
jester5 48 minutes ago 0 replies      
Honestly, This is going to sound slightly mean and unrealistic but I think it would work. I would have them start with Assembly and then dabble with C++. At 12 years old they can dedicate lots of time the concepts. Yeah they might not be deving anything cool right away but it the long run they will be amazing.. So I suggest Assembly, Visual C++ using Visual Studio.
2
nextparadigms 2 days ago 0 replies      
These are nice for Android development:

http://www.youtube.com/playlist?list=PL34F010EEF9D45FB8

He might need to learn some Java first, though. Thenewboston has some nice Java ones, too.

3
shyamster 2 days ago 0 replies      
Heard good things about Stanford iPhone courses on iTunes - http://itunes.apple.com/us/institution/stanford/id384228265
4
connect_vipin 1 day ago 0 replies      
This is very great a 12 year old boy wants to develop a application .....
let me suggest some points first of all developing applications is very challenging n interesting ....There is no end of developments but there are some starts which is very necessary for every developer to learn ...Microsoft provide a free tool kit of their products called
Visual Studio 2010 Express Products here is d link
to download

http://www.microsoft.com/visualstudio/en-us/products/2010-ed...

where every person without paying.... start making web,desktop & mobile applications for personal use specially kids which is the best part over their is a kids corner where kids learn how to make , design applications and learn basic programming oops concepts with help of videos specially for kids

http://msdn.microsoft.com/en-us/beginner/default.aspx

....after all this stuff u start looking deep in open source tech like java n android .....their are lot of free tutorials channel in youtube New boston is one of them and many paid tutorials lynda, video2brain ,nuggets so many.........Thanks

5
zeroxsys 2 days ago 1 reply      
Advise him to learn the concepts on software engineering. Starting with software design using models/diagrams. It's a good way to visualize his app and the overall project. Then, he could move to coding using tutorials available on the web.
6
firefox 2 days ago 0 replies      
The same thing you'd advise a 40 year old ;)
Also check udemy or lynda.com for some great intro courses
30
A social network with file sharing. Why not?
3 points by starter  2 days ago   3 comments top 2
1
ajuc 2 days ago 1 reply      
There is similair network in Poland ( http://chomikuj.pl/ ).

It's mostly used by pirates, and social aspect is not the main functionality (you can add comments, images, recommend people to other people, share their files, etc. , but that's all). Most people think of it as an alternative to rapidshare. They earn money from users paying for downloading transfer (uploading is free, or even gives you points you can use to download other files, I don't remember).

I wonder how they deal with copyright - maybe because you are supposed to know everybody you share with - it is fair use?

Anyway - it exists.

2
anPlusD 2 days ago 0 replies      
thanks for your input for anon+ :>
       cached 16 September 2011 19:05:01 GMT