This document is guided at SDSLabs members, but should be equally valid to anyone working in technology.
I've tried to keep all advice language agnostic and independent from any technology. This is like a series of short blog posts I've condensed to a single gist. Feel free to fork and give some more of such advice.
From a github talk about how to improve your organization:
(I can't seem to be able to find the exact talk, so this is paraphrased.)
After all, that is what software development is all about. Reducing human effort, so it can be put into better things.
Learn the basics of shell scripts. Or just write scripts in your favorite language. I wrote a program in php to sync my playlists with my cell phone (after compressing them). And several other such small things.
Technology is an easy field to be in, if you want to get behind. The odds are that softwares five years from now will be done on technologies not invented yet, programming languages not yet written, and will run on hardware not even thought of yet. This is what makes this field so exciting to me.
No matter what you do, you cannot predict what the top gun would be 5 years from now, effectively making your knowledge redundant, or so it would appear on face. But no, as long as you keep yourself from being restricted to a single piece of technology, you can fix this.
Keep on top of happenings. It is not necessary to try everything out. Stable applications require stable technologies. I'm not asking you to jump on top of every brandwagon that comes along. But it won't hurt to keep a ticket handy, just in case. The least you could do is remain aware of them. Research them a bit, possibly, and never, ever let the fear of learning a programming language get to you.
This is not just true about technologies, but also about applications. I was one of the early adopters of Dropbox, and hundreds other startups since then. Join an amazing group of people. Become a critique. Make your own opinions, and hate a few things.
And offer feedback. If I like a product, I am one of the first people to send off a thank you note. Offer sincere feedback. Let them know of your expectations, and what you'd like the product to become. If they refuse, spin your own!
As a penetration-tester, I've found lots of xss vulnerabilities on new products. This is one way I get to learn stuff. Report them responsibly.
A lot of this is opinionated advice, so please take it with a pinch of salt.
| { | |
| name:"Test Blog", | |
| twitter:"capt_n3m0", | |
| email:'nemo@sdslabs.co.in', | |
| url:'http://captnemo.in', | |
| } |
Learning new stuff has become so damn easy now. Even if you, like me, don't have a dime to buy books. Especially if they are unavailable in your country, like me.
Hackershelf is a good place to find good books. So is Zed's guide to Becoming A Programmer. Amazon offers some excellent reviews.
Learn to skim through books. That is an excellent skill to have when you are in a time-crunch. There are so many good open-source books that you can actually contribute to on github today. Go find them.
Let's go to science for a moment, and then we'll come back to the point.
Wikipedia on Scientific Method:
Scientific method refers to a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge. To be termed scientific, a method of inquiry must be based on empirical and measurable evidence subject to specific principles of reasoning.
Back to the point of debugging:
This is the gist of what I'm trying to say. Everyone agrees that self-learning is the best kind, but what when you are stuck? This is the point to bring out your arsenal of scientific tools. Don your thinking cap, and empirically determine how to proceed.
Is it getting vague? I'll try to explain with an example.
The only true way to debug something to experiment with it, shake it, stir it, and then observe the changes. Usually, there are lots of tools that help with debugging a program, which allow you to set breakpoints, check value in runtime and so on. These would be advanced tools. But even simpler tools can do the job.
Binary Search For Bug a<------------>b If you somehow establish that a bug comes from between a and b, you can just comment out half of what comes between a & b to figure out which half the problem is coming from. Recursively repeat till you find the offending code.
Tracing Function Calls If you are not getting the expected value out of a function, trace the input backwards till you get to the point where the bug was introduced. Keep on making measurements to determine when to stop.
Log stuff Just putting in a couple of console.log statements through your code goes a long way in finding that bug.
Google You reach an error message, which opens up a whole new world on google. Never underestimate the power of googling. I wrote a Hash Crashing Contest (http://hashdash.co.nr/), and as it turned out, almost everyone reached the answer by googling the hash, something which I had never anticipated.
Write tests. And write them first. That is an easy way to assure yourself:
TDD (Test Driven Development) is a very valuable approach to take. It helps you in so many ways, but is definitely harder to get used to.
Try out a small project and use unit testing. You can even pick any of your existing projects and write tests for it.
Use a testing framework, because they will be universal, and working on any one will be absolutely essential.
Also, each time you catch a bug, write a failing test for it, so that it never happens again (and is caught the next time).
