anders30

Last year, an Innovation Hero championed a completely new build system based on their homegrown version of asdf, essentially.

I was the one who had to stay late multiple Fridays making sure our Formal Builds would still work. I've been working to roll back the least well executed portions of this innovation for the past year because it doubled the amount of time required to release our software in the last stages of the pipeline (which was already five days, another rant, I work at VeryBigCo on a mixed HW/SW product).

I believe in this story the entrepreneur referenced worked to clear all similar hurdles, but it's hard to feel bad for folks who view themselves as Innovation Heroes when in many cases they're applying solutions in search of a problem. It's also very not fun to be "that person" aka "The Adult in the Room".

Yes, today the "Innovation" is part of our processes, but in stripped down form and it cost us two missed formal builds with the corresponding loss of credibility in our customer's eyes... in addition to my own sour grapes and missed dinners with my kid. It also cost me a personal friendship with the hero (my fault, but it's really hard for me to get past the fact this individual put their ego over my time with my family).

Agree it's a sign of a dysfunctional organization but it goes both ways. As an Innovation Hero, you should be aghast at how inefficient your org is, but as a part of that org, you should stop and ask, "How did we get this way and am I sure my solution truly solves all aspects of this situation?"

I think your point here should resonate louder (at least where I live in the USA).

Jumping in and out of the "gifted" track should be possible if such a thing exists; however to your point, how would the track be defined and what should it contain? Would there be a list of items that need to be mastered? What evaluations determine if you can jump in... or when you need to "jump out"? Would the "gifted" track be age based the way it is currently or could the contents be tailored to fit the needs of the individual students?

Following that line of thinking, at what point do you qualify for a job? Also, what social stigmas would we attach to "jumping out"?

I don't have answers, but your point led me to some very interesting questions. Thank you!

I would prefer the SVG itself but this is an ideal short term solution. Thank you very much!

This is a wonderful tool for simple flow charting. I agree with other posters that a little more documentation would be nice and would also like to request the ability to export the underlying SVG (I'm still browsing source to see if that exists). I'm willing to help add both, thank you for this!

I agree with your comment but I wanted to share:

I have constructed the argument before that if you consider functionality as an asset and code as a liability, you can consider a refactor as retained earnings (or stockholder's/owner's equity, whichever you prefer). Along those lines, refactoring code becomes much more palatable.

I know it's a flawed analogy because refactoring costs money, so it isn't really RE. It did help me answer a question along a similar vein to yours ("...how do you see your balance sheet improving while still being balanced?"); where I was assuming a reduction in liabilities satisfied "...balance sheet improving...".

Yes and, since I had a good manager, I was rewarded when "the next person" came along and the amount of time required to onboard dropped from one month to two weeks.

Everything in that situation came down to documentation and I spent my first couple of days just chasing down the "correct" IT person to setup all of my accounts (company network, version control, bug tracking software, customer network, remote access, email - each required a different person and I had to ask around to find out who they all were). I commented that having one IT person who can handle everything would be ideal; but I had to settle for creating a list of "who to contact for what". This still shaved days off the next person's lead time.

Simple stuff like having a development machine ready to go (installing Visual Studio, an Office suite, etc) when the new person arrives really makes a difference. There was a learning curve w/r/t the actual system but the new person didn't have to switch gears between hunting people down, installing a myriad of in-house software with which they have no familiarity, and other general "drinking from the firehose".

I took some stabs at making the firehose drinking not as overwhelming; but I didn't do as well as I wanted.

The organization's attitude mattered, in retrospect. Bringing on new people took a significant amount of time (still does but it's better) and everyone did what they could to help me document the process. I imagine if the organization had not been incentivized to help me, then I would have failed and "first write the documentation" would not have worked at all.

I think the McMansion idea is great.

I had a flashback of playing the board game Clue (http://www.hasbro.com/common/instruct/clue_%282002%29.pdf) with my siblings when I was younger. Specifically, I imagined a small team of developers in a large McMansion-Office trying to debug a large application saying things like, "I suggest the bug was commit'd in the kitchen, by Tom with his Custom Arch Laptop."

My statement on the 60/40 work/life balance was a conclusion based on my own bias, which I forgot to specify.

Thank you for your feedback! You are correct that the best hires tend to pursue employment that complements their "spare time activities".

In my experience interviewing candidates, cultural fit largely outweighs other technical merits. I try to keep this in mind when I'm asked for my opinion.

While the questions in this article appear biased towards a 60/40 work/life balance, I would say they're spot on in detecting a very specific cultural fit. If nothing else, these questions would get a candidate talking. They're a little on the aggressive side for my interviewing style, but I imagine they're quite effective.

Keep in mind, the job candidate should also be interviewing the company. If someone were to ask me what unpaid work I have done in the past, I would consider the cultural ramifications of the question. In this case, I would need to be okay with an aggressive internal culture.

Come to think of it, it's important to realize that when you interview candidates you may very well be the first impression of the company. Articles like these offer a glance of a company/interviewer without having to go through the trouble of applying.

I would really like to find a way to study the effectiveness of interviewing styles. I wonder what metrics would even apply?

I don't have any factual link handy but don't a small percentage of startups take off? I remember reading here on HN that a VC will invest a little money in a lot of companies knowing (hoping?) that most ideas will fizzle, some will do okay, and a few will make millions or more.

Having grown up with Google, I had hoped to see Web ads as their first Unicorn and expected more of the side projects they let their employees work on "take off". It's certainly not for lack of trying; it would be very interesting to summarize Google's pushes into other markets and see why they have failed to expand their core competencies.

Google has in no way failed, but I have always expected another PageRank type success somewhere.

This looks like a lot of fun but I'm surprised to see this in Java. Nothing against Java, the JVM, or the ecosystem surrounding it; I expected to see a REST interface, or something similar.

Having read Artificial Intelligence: A Modern Approach (http://aima.cs.berkeley.edu/), I think it would be a neat side project to abstract as much out of the intelligent agent model from Chapter 2 as "makes sense" and see to what extent you can allow interfaces from any programming language.

I recommend looking into a large company that lets you move around (specifically let me recommend Boeing). I have changed groups several times and there is very little stigma assuming you can get yourself up to speed in a reasonable time frame and you're not, "leaving behind dead bodies".

Consider reading a book called, "The First 90 Days: Critical Success Strategies for New Leaders at All Levels". It's contents helped me gear my interviews towards how and when I would add value to a new group. I believe that is the key to changing jobs - average time to positive ROI from the new group's perspective, not average time spent in a group.

You have some great recommendations in this thread, so thank you for asking!

You are absolutely correct that he does not accomplish these things on his own. That is a valid point that can be said of many people today.

Having read books like "Good to Great" and "Creative Capital" and given my own personal experience at a large company, I raise Elon Musk to the "Super-Man" level because of his leadership. Consider the technical challenges and setbacks that his companies (Tesla and SpaceX) have faced. It is no easy task to maintain the vision and energy necessary to motivate the thousands of people who work for him in the face of such issues and audacious goals.

I don't really consider him Super-Man by the way and I have never met him. I only know how difficult realizing my own visions in life have been. To be in his position certainly requires more of "something" that I am yet to discover in myself. I therefore consider him worthy of my respect.

Consider the field from its inception and how it has changed over time. We move into higher abstractions and release ourselves from having to worry about details such as memory management. Even so, as an embedded software engineer I find myself wrestling with memory usage and throughput budgets. As AI becomes reality, it would be ideal to mold (evolve?) an AI to help me address specific weaknesses in my capabilities to allow me to focus on "the problem at hand". If you're curious about that sort of AI development as it relates to embedded software, check out "hyper-heuristics".

You can really answer your question according to the observable trends of the field. The role of the "programmer" will shift, that's all.

Regarding what a programmer needs to know, I think you'd be hard pressed to find something that wouldn't be useful in some way. Personally, I am trying to read as much of the "Old Masters" as I can. I've started with Claude Shannon and have tried to hit all the big names along the way. Bernard Widrow's work (http://www-isl.stanford.edu/people/widrow/publications.html most articles are free) got me started.