4 ms·
Go read open source libraries. I started out barely knowing anything in Javascript and I had terrible code, as almost any dev could say. However, I was never
by mpolichette 10y ago
Go read open source libraries. I started out barely knowing anything in Javascript and I had terrible code, as almost any dev could say. However, I was never afraid to follow the debugger through the code of the libraries I used. At the time these were things like Backbone and Marionette, which have incredibly clean and well documented code.
Find a library you use and have a feel for how it works, and read through their code. If you run into questions about why something is done a certain way, they'll tell you! Use git blame and see what the commit message was for those lines! Often there will be a description or issue tied to it and you can figure out the thought process they used. Then just start applying similar thinking to problems you encounter.
- sjs382 10y agoThis. Just familiarizing yourself with developers of popular/widely-used codebases helps immensely. Make sure to stray outside of your peer group for this, too.
- kzisme 10y agoAny suggestions on how to get outside of your peer group?
- biot 10y agoSome good advice here: https://news.ycombinator.com/item?id=12002315 https://news.ycombinator.com/item?id=12002315
- sjs382 10y agoIf you're a WordPress developer, look at some non-WordPress projects. If you use Angular all the time, check out some React projects. Use Bootstrap as a starting point for websites? Check out Zurb or any of the new CSS frameworks that are posted here every week. You don't have to switch... Just become aware of what others are doing.
- eyelidlessness 10y agoIn addition to the other suggestions, take a personal interest in technologies you may not be able to use professionally. If you write Java at work, maybe go learn Erlang. If you build web pages, go learn database optimization. If you do anything other than security, learn how exploits are discovered.
- tzs 10y ago> Go read open source libraries. That can be good, but some caution is required I believe. Most developers are writing programs to solve a fairly specific problem operating in a fairly specific domain in a fairly specific environment. They may choose a variety of programming styles to approach the problem (imperative, object oriented, functional, and so on). I'm going to call these kind of programs "normal" program. Libraries are not normal programs. They are tools or components that are used by those writing normal programs. A good library tries to be accommodating to a wide variety of normal program styles, and tries not to impose too many constraints on how the library is used. To achieve this, library coders often have to do things that would be poor style or poor design if done in a normal program.
- bordercases 10y agoThis is an important point. Fully generalized, though, and we find idiosyncrasies in every application domain. Maybe starting with a project like this would help? https://github.com/aosabook/500lines https://github.com/aosabook/500lines