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.
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.
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.
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?
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.
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).
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?
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.
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.
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.
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.
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.
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.
But we've cherry picked the CVs a little. And probably only interviewed 50 people over the past couple of years. (And hired 5)
Our success rate is surprisingly low.
I really like this idea, would use it a lot on the upcoming days.
Great idea and nice simple execution, just reviewed a few sites!
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).
Thanks for making this.
Edit: I keep getting the test site asking me to skip. Maybe you should remove it?
Publicly we use tenderapp. Always loved their design and UX flow.
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.
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.)
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).
Another one i'm also testing is an indie game marketplace.
PS: liked http://www.kiveve.com/
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.
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 ?
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.
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.
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.
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. :)
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.
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
- 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
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/
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.
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.
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.
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.
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.
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.
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.
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).
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.
Any time somebody says they feel like you do, I throw them a link; it seems to help.
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.
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!
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.
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.
"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."
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
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.
Also - consider buying code reviews from developers you respect - even a couple of hours a week can make significant difference to your quality.
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.
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.
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
Just in time, not just in case.
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 :-)
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.
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).
His recommendation boils down to keeping doing it until you code matches your expectations.
"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.
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.
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.
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.
That's how you improve at every craft.
But oh well. Shit happens, and my code got me this far.
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.
Remote pairing is pretty easy these days with SSH, tmux, and VOIP.
In my own experience, mathematics is the only way to gain assurance.
Keep coding, and as always ask the developer community for help and advice, stackoverflow has certainly helped me a lot.
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.
a cleancode frantic
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.
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.
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.
He might need to learn some Java first, though. Thenewboston has some nice Java ones, too.
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
....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
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.