jwitchel

I just couldn't sit on the sidelines any more.

After that leap it was simply aligning my personal skills with various opportunities until I found a good fit. I looked broadly for a while: reforestation, fintech, residential installations, real estate, utility scale, training, open source, enterprise software, venture, etc. And I'm fundamentally an entrepreneur and a capitalist so I looked for problems through that lens.

But for me that process began with the same basic question every engineer has almost every day: "What is the problem, and what can I do to help fix it?"

The scale of our global energy infrastructure is incredible so small gains can have outsized impacts. I encourage you to just dig in.

Solar is a fantastic industry. Lots of room for improvement feels like internet did in thr mid 90s. Just a ton of enthusiasm and a sense you're part of something big and important.

https://www.aurorasolar.com/ https://utilityapi.com/ https://www.folsomlabs.com/ https://www.sighten.io/ https://www.energytoolbase.com/ https://home.alsoenergy.com/

Climate change is (often/best seen as) an economic problem. Companies that cut the cost of renewable energy are the ones that matter. Soft cost reduction (as opposed to silicon wafers, transformers, etc.) is the best place for software to make a difference.

Disasters seem to be regrettably a growth market these days.

Help. Don't help.

But sneering at their effort is just mean.

Bravo and +1 to all the engineers on this very excellent project.

It's a very good gentle intro to syntax and the basics of functions, variables, etc.

However, a word of warning. JS is a double edge sword as a way to learn concepts of programming. It's awesome because you can do fun stuff on a webpage fast so the positive feedback loop is rewarding. But JS also has some peculiar behavior that can be hard to grock and debug if you don't have your computer science fundamentals down or at least someone to help you over the hump when things get weird.

2. Rotate who reviews so everyone gets a chance to review everyone and put yourself in the rotation.

3. Lead by example. Write some code into production and submit yourself to review. Everyone writes code, everyone reviews, everyone gets reviewed.

4. Each review find just one thing to refactor and let them know they should be looking for the same thing in other people's code.

The original idea was simply that if everyone could see everyone's lending activity it would yield improved loan default rates across the board thus leading to lower lending rates.

The thinking was somewhat more optimistic than an unattended prison and reflected a personal belief that, as the saying goes, sunshine is the best disinfectant. Meaning, it's harder to publicly default on people that you know than it is to default on a multi-national corporation.

The other touchstone was "It's a wonderful life" -- specifically the scenes in the movie around banking. In fact we originally wanted to name the company "Bedford Falls".

FWIW.

Regardless of whether you outsource to India, China, or a a guy down the block many of the same issues apply.

1) Can you fire the company if you need to? "All relationships end badly or they wouldn't end." When you have to fire the outsourced team, do you have the skills internally to take control before you find a new group?

2) Can you ensure the outsourced team doesn't do anything sketchy. Do you have a team internally that can protect against back doors, lockout triggers for non-payment, inappropiate code insertions, undesired use (or non-use) of GPL'd code.

3) Due-Diligence. How (specifically) do you plan to get through due-diligence -- not just with VC but with an acquirer who will look at your code and how it was developed? Code review, architectural review, etc. Without a local team firming at the helm that process will go poorly and cost the company far more in a valuation hit then any cost/time savings.

4) Customer Data. Although it's just about impossible to avoid giving a remote team access to your customer data, you can't give them total control. You need a strong DBA locally to ensure your DB meets your security and privacy standards.

5) Around-the-clock development. The reason outsourcing is effective is not because it's cheaper (it's only marginally), not because they're better (they're the same as us), it's because you can do around-the-clock development. They check in code at 6 AM your time, you check in code at 6 AM their time. That's how you get ahead. If you simply transfer a single development team to a different time-zone, all you bought yourself is a 20-30% cost savings and a bunch of frequent flier miles.

So the net-net on your pitch is: control, intellectual property ownership, customer data, and speed.

I suggest you pitch: a) Acceptance testing stays domestic b) Design stays c) Software Architecture and Spec Writing stays d) Small team of the very best developers stay e) "everything else goes"

The first thing I do is research the daylights out of every competitive product I can find and compile a super set of features of all of them, noting pricing, positioning, messaging, etc.

Then I circle the features that matter to me and I add my own secret sauce features. Then I turn the computer off and start sketching.

Sketching isn't the act of coding or even designing. It's the act of thinking. Look at Leonardo's sketches -- particularly the ones of the human body. http://www.drawingsofleonardo.org He isn't documenting in so much as he's working out what he thinks about how something will work, not just on the outside but on the inside as well. This is particularly true for his anatomy sketches. IMHO he would have been an awesome software designer.

I believe that coding is the art of thinking clearly. Lack of clarity in what you're building almost always results in bad code, the kind that no amount of tweeking can fix.

IMHO the absolute best prototyping tool out there is graph paper and pencil. Personally I like the marbled notebooks because they can take a beating and you can write on them reclining.

Once you've got all the screens of your site drawn out and even some copy written in the margins then you can turn the computer back on and revisit each of those competitive sites and see if your idea still hunts. If it still does then start coding.