Semi-related.<p>Whenever I'm building something, I get <i>really</i> strong tunnel vision. Part of what makes me a good engineer – submerging myself extremely deep and specific context, "the zone" – seems to work against me becoming a good product person. There's always product stuff I seem to forget, or don't pay attention to, or I end up focusing on the wrong things.<p>After "shipping", however, the tunnel vision goes away. I can view my work with a level of clarity. Some features I built might be valuable, and some won't.<p>By splitting my work into build/evaluate phases, rather than continual building, I've become much better at focusing on the <i>impact</i> of what I'm building, and not the engineering in-and-of-itself.<p>I have a terrible habit of spending too much time building, and not enough time thinking/marketing/etc. This is how I try to manage that.
Being old enough to have used both Microsoft and Borland development tools back in the 90s, I think Borland was clearly ahead of the game in Windows development. GUI development with MFC was clunky and tedious. Tools generated ton of boilerplate code that you had to understand and maintain. Borland on the other hand offered much more developer friendly experience, especially when Delphi 1.0 came out on 1995. That was hands down the best development tool for Win16. They maintained the edge in Win32 development as well with Delphi 2.0. So, seeing all the dirty tactics MS employed to steer developers to using their tools just reminds me what an a-hole company they used to be.
I am not a fan of the term "ship", similar to "sell". It's a horrible term. It evokes the image of a frantic imprudent developer churning away at ball of mud trying to meet their shipping metrics and feature bloat targets.<p>Does anyone feel the same? If someone told me "I sold stuff, therefore I am", it just leaves a bad impression of them for me.<p>Build stuff with care and craftsmanship. Strive for excellence, take pride in your work and deliver, not ship.
> The biggest lesson a new team can have about shipping is that once you ship, it gets easier to do it as a team the next time.<p>This is so true, and not only in software development. When you embark on a project that has to deliver a concrete result, the first time is hard, the second time is already much easier.
> Visual Basic pioneered the concept of making it easy to code GUI programs. The problem was that it was not viewed as a professional tool and was much more geared toward business app developers and not commercial C programmers<p>IMO nothing came close to Visual Basic from that era. It really was a GUI builder IDE all in one.<p>It would enforce a event based style of coding a decade before the coming of Flash. I still think HTML5 has not recaptured that (VB and Flash).
reminds me of a joke; Renes Descartes walks into a bar. bartender asks him "a pint, Sir?"<p>Descartes answers "i think no-" and promptly disappears.