I'd read managing humans, and other people skills books. You will most likely want to learn how to rely on your peers to build better software than you. Your job as a leader will be more important in your ability to make sure your team is doing the right thing rather than how they do it.
I followed option A in my career. I quit, went back to school to finish my degree and worked part time as a contractor for enough money to maintain my mortgage while in school.
Anyway, it is very important to learn to work closely with a team. It is also VERY important that you work with people that are SMARTER than you. IMHO, this is the best way to get proper mentor-ship and motivation to learn. I personally try to surround myself with people that are smarter than me.
Once you think that you know "everything" or that you're the smartest person in the room, it's time to change jobs. Because:
A) People won't like working with you
B) You'll stop learning new things since you already know everything.
Why is this? If enough people follow the "work with people that are SMARTER than you", which I think it's really important and I hope a significant number of people follow, why wouldn't they like working with you?
Thinking you know everything is a definitive sign that you do not!
One of the first lessons you learn from experience is that what you thought would happen, doesn't.
In other terms, you have cognitive biases, emotional biases, and filters your brain uses as information you process goes from perception to short term memory to long term memory...and lots of things get lost in the process.
If someone isn't smart enough to realize his perception of what he knows is colored and influeneced by things outside his control...he probably hasnt had even close to enough experience to be humbled.
Reminds me of the saying, "a specialist is someone who knows more and more about less and less until they know practically everything about pretty much nothing."
It's when you start to think you know everything that people don't like to work with you. I haven't met that many people in my software career ~15yrs that have enjoyed working with a know-it-all.
You can of course be super smart at your job and know a TON, but when you start acting cocky and like you know everything it usually doesn't end well.
I can tolerate know-it-alls when they really do know a lot more about something than I do and are willing to share.
However in my experience, the majority of people with a know-it-all attitude are simply blowing hot air and trying to cover for the fact that they really aren't nearly as smart or knowledgeable as they would like to be.
Most truly smart and knowledgeable people I've met have been amazingly humble and usually fairly quiet about things. The qualities of quietness and humility lead to learning.
This looks great! I'll be downloading the trial for sure. I wonder if it'll work with gdbserver for remote target debugging? UndoDB's site says it works for Android, but they mention that it's native Android not remote. Anyone have any experience with that?
UndoDB comes with its own internal replacement for gdbserver called undodb-server; you can do remote debugging by running undodb-server manually on the target machine and connecting to it from within undodb-gdb. The README has an example.
This is pretty awesome! In the past I worked on a project which we implemented a control-plane/data-plane separation architecture within Linux. The system had two CPUs and we had Linux running on one with configuration apps and all network related IO ran on the other CPU.
The problem was that this was implemented at the kernel level and whenever an application needed to share data across the CPUs it was slow. The implementation could have probably been better, but this was a long time ago and I can't recall everything that was done.
Regardless, Arrakis looks like a great project with a lot of potential.
Imagine this type of stack being used in an embedded system. I've worked on embedded projects that achieved high throughput but in most cases there were FPGAs and DSPs doing a lot work to help. Userspace-to-Kernel context switch delays have always been a latency issue with any Embedded Linux system I've worked on.
Arrakis looks like one would be able to achieve high performance without the need for FPGA and or DSP (depending on the use case of course).
Side note:
Cool, I noticed they're using lwip from Adam Dunkels. He's an amazing programmer.
$8.50/hr may be a lot for where OP lives based on their experience. I would think that OP is not living in the US. Hopefully OP can provide some insight here.
$8.50/hr is a nice amount of money in Hungary for example. If you don't have a finance/compsci degree is way above the average. In compsci, its an average payment for a developer with 2-3 years of experience (no need to pay further tax anyways from this).
Architects, lead devs, PMs earns around 15/hour at best paying companies. If you're a contractor, it could top up around 20 after taxation.
A young person with an average degree (economics for eg.) in an average position is not earning more than 5/hour here...
Not to hijack this thread, but I'd like to hear more about remote rates of other platform developers as well (php,nodejs,python,.net, etc). A nice comparison matrix would be awesome. Anyone know of a site that specifically compares these rates across the globe?
I could see a matrix like this being a great addon to remote job sites. Those of you who have created a work-remote job site and are competing to weworkremotely, etc... I would think that this would bring you a lot more traffic.
Although I use git these days and wouldn't go back to P4 if you paid me. I still sometimes use p4merge for my difftool and I always thought they did a great job with their client UI with Qt. So, yay for p4 and Qt.
Funny, while I love Qt, and have been using it in our internal tools, there is a old-lore & myths about p4win (the MFC version) of the tool - that always felt snappier than its successor - p4v - and yes, p4win is snappier, but sometimes its just the fact that you've used it for so long, its hard to get without it.
Just about any big game studio uses P4 these days. I haven't seen one that doesn't.
"Just about any big game studio uses P4 these days. I haven't seen one that doesn't."
That's a very interesting statement. I wonder why? Maybe it's just grandfathered into these companies. IMHO, even if you're an enterprise software shop I think git can handle that with the proper tools and practices.
I'm currently having to use Accurev in an enterprise environment, but I haven't run into anything that Accurev offers that can't be accomplished with git in a better and faster way. But then again, that's just my opinion :-)
P4, as much as there are aspects of it I hate, handles the situation where you have binary files in the repo much better than most source code control systems do... especially git which sucks at that[1]. Game companies tend to have potentially quite large (by SCCS standards) binary assets mixed in with the code or even when they are cleanly separated, they like to have the standardization of everyone using the same version control system instead of having something separate for the artists.
([1] Predictably someone will probably want to respond to this with some link that shows a complicated and non-intuitive way in which you can get git to be halfway reasonable with handling binary files, though this will just prove my point more than disprove it, when compared to P4 which just handles binary files great out of the box with no thinking or planning required).
Every time you make a change to a binary file, git will make a copy of the entire thing and attempt to compress it (despite the fact that it may already be compressed as part of the file format and won't compress any further). And because of the distributed nature of git this means each client is going to have who-knows-how-many perhaps barely different versions of each binary asset, which could be megabytes to hundreds of megabytes in length per version and woe be unto anyone who has to clone the repository for the first time when coming into the project (be prepared to wait hours, maybe days).
There are various git methodologies and projects (eg. git-annex) aimed at working around this but by default git just wasn't designed to deal with big repos full of big files.
OK, I get it. The hashing would become slow on each file (especially large ones). And given that git is designed to give you the whole repo history, yes, cloning would be slow with repos with a lot of history.
It seems like 2 of the main reasons Perforce works better with binary files is that when you sync, you only get the version you're requesting, thus resulting in faster downloads and there's an option to disable compression.
Yes that's exactly correct. On the client-side P4 basically only really cares about the current version (or whatever branched/changelisted revision you are working with) which for projects with a lot of files (especially binary files) will be an incredibly smaller set of data than the full history. git is fully distributed with all of the pros and cons that come with that.
