They are part of the Summer Class of 2015 for Y-Combinator and are really promising. You basically sign up to be a Gigster and then get paired with gigs that pay. Within a week you could be up and running with real projects that actually pay.
Gigster handles all the PM and HR related functions of a business and quickly gets jobs to you so you can start right away.
You have to look at this in a different light. Making a difference as Software Engineer is possible. But digging deeper into the root of how its possible is not a career related move. Many people make tremendous contributions everyday (i.e. See Github) in many fields everyday. However, your determination and drive as an individual will deter your actual affect on the world. To put it simply:
We choose to become leaders. We choose to change the world. No one is born* into it*
In the massive wealth of technology and information we have today, it is very much possible to become successful as an engineer. But much too often do people outweigh the failures of the many with the successes of the few. Think of how many startups have failed before one actually succeeded. It is ungodly and daunting to look at the statistics but that should never stop someone. It should drive you as a professional in not becoming one of the many and deciding to fight to become one of the few.
TL:DR; I do not believe that being a software engineer alone gives us all the capability of changing the world. It must be coupled with drive and determination before it becomes an option
I've been hacking away on a game boy (not advance) emulator myself lately. It's actually all pretty well documented, even if you don't look at other emulator source codes, and the hardware isn't too complicated.
I enamored the man for his work and his experience with developing truly innovative work while still pursuing an active "side project" go-getter-ness via Codepen. But after seeing his appearance on Envato's "Made By" series, I could not have chosen a better role model. He is exactly what I want to be in the future. Calm and Collected and revered as an expert in my field.
It's a whole new world. It reminds me a bit of 2007, but even more intense. And although I wasn't in Silicon Valley in 1999, it has some of those overtones, too.
But the biggest change is not in all that noise, it's in the fact that entrepreneurial know-how is widely available. When I first started blogging in 2008, there weren't that many startup blogs. Almost no VCs blogged. YC was just beginning and PG's essays were about many different topics, with startups appearing only rarely.
Now new founders are swimming in a sea of knowledge that was previously considered esoteric. I think we're only seeing the tip of the iceberg of what will happen to the global economy now that the genie is out of the bottle. (mixing metaphors a wee bit)
I would trust documentation with a grain of salt. Very rarely do I find intensive and accurate documentation for distributed systems. However, documentation may be helpful for things such as stand-alone components and REST endpoints. Those would be taken with possibly 2 grains of salt.
The one thing that you would never want to do is actually read through the code line by line*. HOWEVER, let it be noted that I mean this as an initial point of insertion. As a Computer Scientist, your first step should be in attempting to ask the right questions.
Think of it like a game of 20 questions ( N questions in this case...). To do this, one of the best things I have done is to follow the process. All distributed systems attempt to solve one or several use cases. Define these use cases and then analyze the code basis from there. For example, a use case that involves a REST Endpoint can be updated your profile photo. The use case would define a point of entry (where/how to submit a new photo) and a point of submission (the REST Endpoint). From this, we can search for two components in the system that facilitate this task.
=== A good word of advice in understanding any code base is that, nine times out of 10, it is ALWAYS easier to read code once you understand its purpose. ===
> Language Specific Strategies
As for some good language specific strategies, be knowledgeable of what Paradigm the language falls into. For example, Java code tends to have a single point of entry for most cases. Whereas Javascript (as a functional language) can have several entry points (or even none at all). For functional languages, be mindful of how they are structured. Functional languages are not object-oriented by nature but they can be if implemented properly. As such, try to notice the key differences (i.e. prototyping).
> Cloud Debugging?
I would not consider it. Debugging should be a constant process of development. Not even the best developers can write perfect code from the start but with enough work and constant QA testing/Unit testing during the development process, any code base can become easily manageable for debugging. In addition, learning how to read Stack Traces can save HOURS of debugging.
> Tracking knowledge from Module to Module
Personally, I keep notes. I pretend as if I am writing an API document. Nine times out of ten, most modules take an input and provide an output after some calculation. So long as the calculation is sound, I do not worry about the calculation and only record the call to the module itself and its return. Other cases like classes can be tracked by the same notion.
> OH THE COMPLEXITY
It's a necessary evil. No one ever said being a developer was easy. And no one ever said the best things in life are free and easy. I work hard for what I do and for what I want. I love my job. I don't think I would ever consider changing careers. Sometimes the complexity does become overwhelming and its hard to handle. But if you wish to know my little secret, schedule yourself some mandatory free time. And stick to the schedule. This doesn't mean try breaking away from the computer, but just do things that help you relieve stress. Talk to a friend and have a drink or two. Developing is tough on the mind but it is an occupational hazard in the least.
> Updating/Maintenance
If it's open source, let the users dictate when the updates should happen. I believe in Agile development and trusting the users. But when it comes to updates and maintenance on a corporate system, always try and set some goals for the change. Why are you updating/performing maintenance? Is it to improve the speed/response time? Is it worth the cost of time/labor?
> GOLDEN RULE: Ask Questions. Be Skeptical and always tread carefully. We are Developers. We are Problem Solvers. Not Problem Makers.
BG: I have 6 years of experience working with Corporate level architectures and distributed systems. And earned my BA in CS minor in Information Systems. In my time, I have worked with multiple functional, object-oriented, and web based languages. I have also worked as a Full-Stack Developer for roughly 3 years now.
I did not think anyone would take time to answer so many of my questions. I agree with you on lots of points you mentioned above. Regarding the documentation I usually trust it if the module or the system is new, but if its old enough, i assume its outdated, architectural drift exists and only take that as a reference of how the system was planned to be like.
This also gives a lot of use-cases to begin with and understand the control flow. Regarding test cases, integration and regression tests help a lot in finding failures but I feel more confident about them if written by the same developer as the original thought for the code change is more pure with him and the reviewer.
For knowledge tracking, I guess there is no easy way, one learns from experience and time, but it would be great if there were some great tools to capture thoughts and map them to a definite state in the application without making any change in the codebase.
I have been in my academics for 6 years doing my bachelors and masters and less than a year in my professional career. The sheer amount of stuff one needs to know about building scalable and distributed applications is just amazing and nerve-wracking at the same time and I will keep your secret in mind :)
Thank you for the kind words! It is daunting to see how much anyone would need to know in order to set up distributed systems. But it is powerful to have. And with great power comes great responsibility :)
They are part of the Summer Class of 2015 for Y-Combinator and are really promising. You basically sign up to be a Gigster and then get paired with gigs that pay. Within a week you could be up and running with real projects that actually pay.
Gigster handles all the PM and HR related functions of a business and quickly gets jobs to you so you can start right away.