There is no surplus of good opportunities for technical folks to co-found something they can believe in. There are plenty of other opportunities of course.
I think the article is solid in that you have to sell the potential technical co-founder that you have a great idea and will add value to the relationship. "decent salary" will get you a contractor for hire, not a co-founder.
You don't have a lot of choice than to network and try your pitch.
Number one on any of these lists should be empathy for users. If you don't care about and understand those using your code, you will never be great, only good.
They return the objects meeting the criteria and you set the property blindly. The query API I saw has a clone and replace API too which is good if concurrency is a concern.
I am not up on this but in XML world I would have used XPath. I see there are both JsonPath and JsonQuery gems that seem to be geared for this kind of stuff.
I think the original Team System pricing which was probably there to compete against IBM Rational in the enterprise ignoring they had a much broader customer base.
They eventually folded it into most of the MSDN freebie programs for partners and startups...
I have to agree from my experience at IBM. Those rewarded tend not to be rewarded much by industry standards (years salary at best) and the entire team or even the most meritorious contributors are rarely rewarded.
I know of at least one team that came up with something major that asked for their compensation to be tied to their product success having their idea moved to another team because "they should do it for IBM purely". Of course that product failed for lack of vision and focus.
From an innovation standpoint, it might be interesting to go with the model of high benefits of success, low cost of failure. That relative skew is what has arguably made the US the leader in this field in the macro.
Startups given the market for engineers in particular actually only have a temporal starvation penalty. It's not like they can't get another job after they fail.
Doing this in a large company might lead to even more innovative products because startups are so under-resourced and governed by promises to investors that they risk becoming myopic and less agile.
It's amazing how many of these so called CS topics that fell out of favor in the 90s have come back in the web world in major ways.
Consistency, concurrency, parallelism, persistence. Yup we're back to basic distributed systems over larger networks.
The vast majority of developers don't need to know all of those things of course, i.e. forms enterprise or some level of RoR applications, but it is kind of interesting to see the resurgence in systems level skills needed in the industry. At one point OS and high transaction developers were down to a negligible percentage of practicing developers and we thought everyone would move to certification type education and high level abstractions.
I think its a good move but it isn't new. I think UC Berkeley moved the first CS class for CS/EECS majors to functional concepts and Scheme in 1989 and MIT even earlier, though the latter abandoned it later.
I remember my Berkeley compiler class implementing Scheme and APL subsets atop the gcc backend as well which was again a doubly good learning experience in learning other approaches to programming and their implications.
I have yet to see OO design taught well outside it's varying programming constructs well. What is the right level of abstraction for "finding objects" in the words of Bertand Meyer?
Could be more of a corporate culture statement than compensation...
I remember one of the promises my manager made me at IBM in the early 90s crisis was that he couldn't necessary be competitive in compensation but I would always have access to the coolest equipment and people... Yes he actually kept that promise, I managed to get one of almost every RS/6000 before they were publicly released in my lab...
I think a lot of entrepreneurial engineers just want to be CTO or VP of Engineering or Product. There's a lot of selling and all that goes around that I think many entrepreneurial engineers are not predisposed to even when they can be good at it.
I know a lot of startup execs and enterprise execs step back after a while to rejoin the ranks of individual contributors for a while to catch their breathe. It was worse during the IPO dotcom boom where I had friends that really felt that as execs they were forced into ethical compromise in handling the finances and misleading analysts when they were running public companies.
Really can't argue with the Oracle that there that the majority of these are over-valued. In a sense that just means they are priced for success though we know many will fail or be limited niche businesses.
The key statement though as it relates to a specific company is: “Some will be huge winners, which will make up for the rest.”
I think the article is solid in that you have to sell the potential technical co-founder that you have a great idea and will add value to the relationship. "decent salary" will get you a contractor for hire, not a co-founder.
You don't have a lot of choice than to network and try your pitch.