How do I push myself from being okay to good to great?

Question

I wasn't sure how to ask this question really, I hope I did a good job of phrasing it.

There are lots of "how do I get started...", "resources for begginers.." or "should I learn..." type questions on Stackoverflow. I have read these post and explored the resources they point to but while I wish I had found them years ago the level they are pitched at is kinda just below (or way way way) above my current skill level.

Without spending too long giving way more background than needed and boring everyone; I'm a web developer, I have been toying with with web stuff for about 3/4 years and have 18 months of commercial experience. I am self taught and have a really good grasp of HTML, CSS, Javascript and a pretty PHP and MySQL in that I know the syntax and built in functions/libraries fairly well and given enough time I can brute force my way to a solution to nearly all problems.

What I'm struggling with is really raising my game, pushing myself from being okay/good to good/great. Like I said, I often end up brute forcing my way to solutions when I suspect more elegant solutions exist by using some algorithm or another. I struggle with big picture stuff - I can solve all the small problems but the solution as a whole often ends up complicated and mish-mashy.

I feel like I have hit a glass ceiling and can't push through. The big problem is that I don't know what I don't know but I know I have so so much to learn.

I am teaching myself computer science fundamentals and basic theory which is helping a lot and am planning on learning another language or two, probably Objective-C and something with a completely different paradigm to PHP/C to help give myself another perspective on problems. I also know that experience is great teacher but that comes with either time or with working underneath someone with more experience and learning from them.

So I was wondering what sort of resources others could recommend for advanced web development?

And in more general and for others that have a similar problem what sort of techniques have worked for people when they have found themselves in a similar situation?

---

You mentioned being bad at big-picture stuff but good at the smaller details and problems. Why not pair up with someone good at the big picture stuff and sponge whatever you can from her/him?

This is actually something I would really like do to but where I work at the moment I have the most experience (it's a really new company and mainly designed focused). I have a REALLY good job so wouldn't want to leave it just to get this sort of experience but I do feel I would benefit a lot from working closely with a more experienced developer.

Answer 1

You say you've been doing it for 3-4 years and professionally for about 18 months, and you say you "can solve all the small problems but the solution as a whole often ends up complicated and mish-mashy".

That sounds like you're right on track.

The only real way to improve is practice. You can pick up tidbits here and there. A great book, a good seminar can be little nuggets of information, but software development is kind of like a language (a real language) - you only become fluent by using it and immersing yourself in it for years. The things you struggle with today, by next year they will come naturally to you and you'll struggle with bigger things.

Someone who has been doing development in about your timeframe, regardless of how brilliant, ought to be about where you are. In a real development team, you would be working under a much more senior person. You would be responsible for these smaller tasks while someone who has been doing development for 10+ years will be looking at the big picture. In several more years, you'll be that person.

There are a few keys to pushing yourself. Obviously if you do the exact same thing over and over, you'll hit a ceiling.

• Find people who are better than you and work with them. You'll be amazed at how much you absorb.
• Learn other languages. Getting a bigger picture of how to approach software development in general frees you from the tendencies a single platform encourages. Learning Java will make you a better PHP developer.

This does have a bit of personal opinion here, but in general (not always) PHP does tend to encourage messier solutions. That's both a strength and a drawback. It's not a formally correct language by any definition of that term. Learn ASP.NET or Java (I recommend ASP.NET). PHP is for solving problems today and moving on. If you're really interested in the big picture, go with something else.

Answer 2

Pick one of the larger web frameworks out there (or even something like jQuery). Use it for a personal project, to get a feel for it. Then, start following along with the community, and ease your way into contributing to the project. Talk to one of the established people, and ask whether there's anything you could do to help.

Nothing teaches you more than working with others to produce code that's actually used by a lot of people.

Answer 3

You mentioned being bad at big-picture stuff but good at the smaller details and problems. Why not pair up with someone good at the big picture stuff and sponge whatever you can from her/him?

Answer 4

What really helped me begin to look at the big picture was Refactoring and Design Patterns...

Refactoring (among many other thing) helps you deal with duplication. When you start seeing or "smelling" those thing you learn to elegantly layer applications, then you start seeing re-usable code.

Design Patterns help to know (sometimes) what to refactor to. All this new stuff comes out all the time (generics, expressions, linq) I use to catch myself trying to leverage everywhere... Design Patterns helped me realize if it really made sense.

Answer 5

• Read.
• Practice.
• Feedback.
• Simplify.
• Repeat.

I'm in the same boat and my method is basically persist, practice, and ask a lot of questions. I don't always write good code, I don't always have good ideas, and I don't always ask the right questions. However, I don't make the same mistakes very often and I'm not going to give up. I'd like to think that I'm getting incrementally better, even if it's only small steps.

In regards to the big picture stuff, look for patterns. Often if you are able to isolate commonalities from various code that you write, you'll be able to extract a pattern.

Answer 6

Code consistently and read smart and relevant things. Keep hanging out on StackOverflow, hang out on programming.reddit, and surround yourself with other wise and seasoned hackers. Read books.

Consistently coding keeps your skills sharp and ensures that you're always gaining new knowledge. The knowledge to build a cohesive large system comes from experience and experience alone. Continually find new projects and things that interest you and code them. Contribute to open-source projects -- this is an awesome way to learn, give back, and improve your resume all at the same time. The people you interact with in the course of that will be excellent mentors.

You'll pick up a lot by surrounding yourself with other skilled hackers -- their experience and wisdom will permeate to your mind to a greater extent than you realize -- but don't be a snob; keep your mind open and listen to everyone credible. This gives you the best cross-section of good and important data!

Computer science changes faster than almost any other professional field out there, and it takes constant diligence and dedication to stay sharp and on top of things. You should do this, but not excessively; time spent coding is often worth more than time spent researching Incubator's newest project, though both are beneficial.

I guess it boils down to the tried-and-true practice makes perfect. It's just as true in software as it anywhere else. If you attentively practice a wide selection of skills (use different operating systems, CPU architectures, servers, programming languages, etc.) and surround yourself with experienced people, all you really have left to do is enjoy the ride. :)

Answer 7

There are things that good programmers learn that simply take time and experience and willingness to learn from what you find yourself doing, often described as "be prepared to throw the first one away".

One of my best stories is how I learnt modular programming. I'd seen it in tutorials several times, but I'd not understood it. At the time, I was writing small programs in C against the Win16 API, scratching itches, basically. A few of those involved the LAN I was using at the time (Banyan VINES) and some simple inter-process communication. Older programmers will remember DDE: actually a pretty clever interface, but a lot of overhead to set things up. I wrote a small library to handle the basics of this because I got irritated copying the code from previous projects to do it. Suddenly, I realized what I had done: I'd learnt how and why to do modular programming.

The point of this story is that I'd found a solution to a problem and had used that to learn. I've since used modular programming techniques times without number over the years and also seen lots the output of lots of programmers who had never had that learning moment. You want to create opportunities for those learning moments. That is how you get better as a programmer.

Answer 8

It sounds like maybe you don't have a formal CS background. If this is true, it might be worth taking a few courses at the local university. In particular, an algorithms course could go a long way towards how you think about writing code. From an interviewing perspective, this is the area I think candidates who come from a self-taught web development background tend to be weakest in.

Answer 9

Ok I have to say hold on a minute here... Some folks have given you way too much of the just do MORE answers. I myself just like you started out as was what I would call.., and many others would call.., a "web head". The scripting paradigm or page by page of functionality paradigm has taught you many great things that you should NOT throw away. That is the first great start you have! Stay in front of your audience and think about their experience. Many times while learning computer science developers become less about what the project needs and more about engineering. I have seen all to often geeks turning out a design pattern under the hood of functionality being delivered that was way more than the business would ever need. Here is the deal...
You need to be able to understand design patterns but you also need to understand anti-patterns to start to understand why you need design patterns. Until you start to categorize why your current code should be improved from a business stand point you won't know that you really should improve it all. In fact from a business perspective doing a page of scripted code might be the best thing to do at your current circumstance. So what if you have to change your code or if you chase your tail forever. In fact some of the most poorly written code for performance is code that is code generated by other geeks but is the best answer when a company just needs a functional application and performance really isn't that large of a concern. You could have a user that is way more willing to wait an hour to do something on your web site if you save him days of work and he gets the application tomorrow. This might be the best thing for an ever changing business who's business process are many and changing all the time. To put in great refactoring on something that gets tossed or to engineer yourself out of complexity before you understand the application's requirements or the application's business fulfillment is just wasting time.., most of the time. If I had it to do over I would start with some principles of good code writing just to have something to judge my even limited coding abilities against. Start with Bob Martin's SOLID principles.
http://blog.objectmentor.com/articles/2009/02/12/getting-a-solid-start Then look at some of these anti-patterns... http://en.wikipedia.org/wiki/Anti-pattern Understanding WHY you should write code a certain way is always in every case better than the super geek that can write for NASA in an assembler. More isn't better.., better is just that better. Better from my opinion is creating as closely as possible what your customer or stake holder needs. Again you might be taking the correct approach right now. People who tell you to know what they know are likely setting you onto another glass ceiling. There are many professions I could give you that really tend to have the same issues in it with their new persons in the professions they are in. They too have two categories. Super geek and those that understand the picture holistically. Become someone who knows more about what is important instead of tooling yourself for every tool choice another person tells you is important and you will find that picking up tools is the easy part in the end. I tell you I'm nobody special at all but I have been where you are and I lead teams of 4 to 10 people on small and enterprise size projects. I have seen many different projects because I am a consultant. I always keep my bag of tools broad and I choose them like using scapel sets. I don't want to ever know how fine the scapel has been sharpened because when that is needed the information on a detailed topic is typically available in the information age in a few minutes time.(i.e. StackOverflow.com)

This is what I would do...
Learn the SOLID OO principles just to have a decent first set of guidlines as a target for coding beyond the adage you spoke of just gettin it done. Next go to the anti-patterns wiki page to understand what you should try to stay away from so you have a basis for your code CURRENTLY and the future. Then pick up a book called Head First Design Patterns because it will explain why you should use a design pattern for a particular business case. Then understand how to connect business requirements to designs that will fullfill your project's needs. For an example don't create web services just because you think you might get reuse some day. Have some solid business requirement state a reason that lines up with reuse and servicing.

Approch is more important thanThe tools for refactoring out there today are getting pretty mature. I know many devs that have said the code base is so ugly that it is a "rewrite". Yet even the most poorly written code has implementation that makes refactoring go much faster than having to do a full blown requirements gather all over from scratch. If you can read the code to understand the need. Then think about the actual need for the application and choose your design pattern accordingly. Past this I would NOT tell you to take on another language. I would however tell you to get good at these topics with your already known tools. Languages are fun and they are revealing but they won't ever make you better. They just make you able to speak to another geek around the water cooler. Don't impress the geeks instead impress stakeholders. You will get choose the tools you want to use and you will get to set the tone and pace for the projects instead of having your hat handed to you.

Answer 10

This is going to seem blindingly obvious, but I think it's something that can easily get forgotten about in the rush to get things done.

When it comes to development experience is the best teacher so try and maximise the amount of experience you can get from the time you put in by actively analysing the work you've done sometime after you've done it.

With the benefit of hindsight the whys and wherefores of mistakes and successes become blindingly obvious.

You'll find yourself thinking things like: "Oh! I'm so glad I wrote that particular unit test - it really helped us when we had to completely re-do the way such and such was implemented", or "Gawd! I hated that blummin' unit test for such and such class so much I ended up having to delete it. It was completely incomprehensible and revolting, no idea what it did, and I just couldn't make head nor tail of it when some changes I made caused it to fail." Then you can figure out what made one test good and the other bad, and hopefully learn how to make all your tests good.

Absorb what you can from the internet/books and experiment with their advice. Analyse some more. Repeat.