Will do, thank you for the offer jbk. Again, great work. I can't begin to imagine how painful it must've been to get everything relicensed! Sometimes it's such "non-technical" work that ensures the continued success of a product.
You are right, of course. "commercial" was the wrong terminology; I meant proprietary, closed-source products as you said.
However, whatever your views on closed source products, they are still quite prevalent. IMO LGPL is a great license to get support from companies that sell these products, while ensuring that your software fundamentally remains free.
Most commercial work these days leverage several open source libraries. And once a library becomes part of your core product, it is in your interest to support further development of that library by contributing code, time, money, etc.
Unlike other OSS licenses like BSD, Apache, LGPL, etc, GPL makes it impossible to utilize the library in any way in a commercial product. My current company works on some video related stuff, and we use OpenCV, ffmpeg etc but we completely steered clear of libVLC due to the GPL licensing (even though we think it's a fantastic piece of software). We will however be revisiting this now due to this excellent work by jbk.
It looks like you're trying to do the right thing here, even though there is no boss or peer who understands exactly what you're doing and can appreciate that fact. Kudos for that :)
To echo tinco's comment, do not try to explain the intricacies of what you're doing to your customers. Put yourself in their shoes and think about what is important to them. Explain just the "end results" of your tooling, emphasizing the points that are important to them and leaving out everything else.
For example, you could say that the caching rework will improve the performance of the system, software-defined infrastructure will ensure minimal downtime in case there's a hardware failure, etc. These are all benefits your customers will understand, even though they may not care or understand how exactly you will achieve them.
It is incredibly important to get your tools right so you can operate as efficiently as possible. At my company we didn't get around to this till much later, partly due to the dilemma you mentioned abt focusing on customer-facing software vs. internal tools, and partly due to the fact that the people who would benefit the most from automation (e.g. finance folks, inventory managers, etc) don't have the same obsession with automating away mundane tasks like us engineers do.
This lack of tools hurt us quite a bit once we started scaling, in ways that impacted some customer relationships (because occasionally we didn't invoice or ship correctly, etc). We have since invested significantly in tools, but we should've done this to begin with.
To make the customer vs. internal tools compromise easier, you may even want to get some basic tools in place via contract work/offshoring and then revisit these later once you have the time/resources. The hard part really is determining what to automate, and how much, and those are decisions that you should make. The development itself can be done by someone else.
Great comment. We're in the enterprise space and we also see many competitors do the tech blog rounds and then fall off the face of the earth after a few months.
To add to your morale point, I look at tech blog coverage as great for recruiting engineers, as that's where engineers tend to hang out to find the next "hot" company (vs. websites specific to your vertical, where your customers hang out).
Not a big fan of the article either, but I think there is some benefit to at least trying to develop some skills outside of your core skill set. This is not necessarily to get good at those skills, but to develop empathy for others who've decided to specialize in those skills.
For example, I've personally realized that management is not really my thing, but having done it for a while I understand better now where my ex-managers were coming from and feel that I'm now a better employee because of that. Same for design work, etc.
And frankly I wish other people did that too. Wouldn't it be great if your manager understood your explanation of why that "tiny" feature will actually take weeks, or the designer keeps potential code complexity in mind when designing something? I think this advice applies to everyone, not just programmers.
Yeah for the closest possible comparison in your scenario, you want to do a 3 year reserved with heavy utilization.
When you reserve an instance, you are committing to a higher upfront in order to get a lower hourly for the reservation period. The low/medium/high utilization is sort of a knob that allows you to further control this upfront vs. hourly cost. With high utilization you have the highest upfront, but also the lowest hourly cost. If you are planning to run the server 24x7, this will also give you the lowest total cost.
Exactly. This was an attack on the new "Uber X" service which will more directly compete with regular cabs. (Frankly the only reason I even take cabs anymore is the cost of the regular Uber service.)
I believe Uber simply sub-contracts to independent sedan drivers who have already jumped through all the necessary governmental hoops - it's not a dispatching system for gypsy cabs. The drivers I spoke to in my city (SF) said that they simply use Uber as an additional source of income.
This is certainly the case with their new "Uber X" service as well that got into trouble in DC - the only difference is that they dispatch hybrids from their partners vs. towncars / SUVs.
Second this. Nothing more awkward than giving notice and then not finding a job you're excited to move to. Unless your intent is to take a few months off anyway, in which case give a solid last date and make it happen.
In fact, in this scenario he can be completely honest and say that that would not be a good idea because, well, he's the main engineer there and they would not be happy about him leaving. I know for me that'd be a very good sign (assuming I believe the guy is being honest).
Second this. Right after school I passed on a higher-paying job to work at a startup. It didn't do well, but I learned a whole lot about what is involved in running a startup correctly, from the perspective of a mid to late stage employee.
Forward many years, and I have my own thing going and I appreciate the failed startup experience because it gives me some framework on which to base my decisions. And I hope I'm doing things better... (and that a few years from now that junior dev we just hired will do a better job with his/her company!)
I think it could be argued though that Jobs probably had a good idea of what is feasible with current technology, and this allowed him to push his team to deliver something that is just slightly beyond the envelope.
I'd consider this similar to how he was said to have very good taste in design, even though he may not have been able to design things all by himself.
Not sure why you're getting attacked. I think the advantage is a combination of nicer design and better PR ("brought to you by the fathers of the iPod", etc). A very Apple-like approach to product. Which works on many folks, myself included.
Well, we have no specific projects for which we're waiting for interns. We'd like to get some smart interns for a while and see what you can do in whatever interests you, and see if it makes sense (from both sides) to maybe turn this into a full-time thing. Send us a note at [email protected] and let's chat.
Also, "Why is it free?" is another way of asking "What's the catch?". It's important to understand this before you put in a bunch of work...