I Shipped, Therefore I Am | Hacker News Reader

I Shipped, Therefore I Am

hardcoresoftware.learningbyshipping.com

301 pointsjashkenas78 comments

Semi-related.

Whenever I'm building something, I get really 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.

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.

By splitting my work into build/evaluate phases, rather than continual building, I've become much better at focusing on the impact of what I'm building, and not the engineering in-and-of-itself.

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.

As someone who studied and worked at art school let me assure you, that this is quite normal.

Some people just are better at changing their doing-hat to the editing- or evaluating-hat in a rapid fashion than others. Being (and staying) conscious about this is already 80% of the solution. However the real reality check is always when you have a room full of people look at ghe thing you made.

If it helps, try to make rituals around the reflection part. Be it something simple as putting your hands into your pockets, making a cup of tea or showing it to a friend. Everything that gets you away, everything that makes you explain it to aomeone else etc. will help.

For me, it really helps writing the documentation. I usually come back and change a feature while writing. I dislike explaining things to people, so I change it as much as possible so it becomes as easy and quick to explain. I call it DDD. Documentation Driven Development.

When possible, I practice full DocDD (DDD is taken). I write a short documentation before the code, write the code, change the documentation to reflect the code, and then change the code to improve the documentation.

You may realise this, but DDD usually refers to 'Domain Driven Development'.

> Some people just are better at changing their doing-hat to the editing- or evaluating-hat in a rapid fashion than others

I only recently realised that, for me, "dev mode" and "product mode" are entirely distinct. I'd been trying to mush them together in a haphazard way, with haphazard results.

In my opinion, this is a really important insight. It's analogous to the De Bono thinking hats, divergent/convergent thinking, etc – distinct phases of cognition that can't happen simultaneously.

> If it helps, try to make rituals around the reflection part.

Great idea! Is this something you learned in art school?

In my experience, every art student seems to incredible at "shipping". I've always been jealous. Way better than most CS or business grads. I guess it's a core part of the degree?

There's the famous study about 2 groups of pottery class, one group was asked to make one perfect vase, the other to make as many vases as possible...

Guess which one ended up with just not more vases but much better quality ones...

Focused/directed practice makes perfect, each iteration your brain is strengthening the pathways associated to that activity, making it easier for you to add more nuance/attention to detail at each iteration...

One can always keep practising without focusing in improving, which isn't as useful...

They idea of turning it into a ritual is awesome. I’m definitely going to try that because it’s something I’ve struggled with in the past. I find building things into habits is the only way to maintain them in the long term.

Strong agree, for me the idea of showing something to a colleague immediately makes me able to view it from a different lens. Regular design critiques are really valuable, even if the person you are showing it too isn't an expert, because it gets you into a different mode of thinking, you can't do mental shortcuts when you are actually explaining things so it forces you to be concrete.

> 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.

I feel a lot of this from the other side of the table. Part of what works against me in engineering is my lack of fluency in focusing deeply on very insulated challenges for a long enough period of time. I've always said this works against me but makes me great at the product side of the house because I can leverage my natural inclinations better.

That was satisfying to read. I think many devs have the same issue and are not nearly as impact-driven as they should be. Let's start another cult : Impact Driven Development

I have realized something similar recently.

When building a website I would use bootstrap or similar to design the website as I implemented it.

Recently I have been designing the website in figma some days, and implementing said design other days, and my productivity had skyrocketed.

For me, it simulates a boss giving me requirements. I can focus on the task at hand without context switching all the time (or that is my rationalisation)

Edit: typos

Yes! I discovered the same thing, but with Sketch. I think it's because you can explore the problem space, and converge on solution, much faster when you don't have to bother with code.

Going further down that line of thought, pen and paper really works. You don't have to bother with colours, fonts and rounded edges.

A fun exercise I do, when solving a creative problem, is this:

1. Divide a sheet of paper into 8 squares

2. Set a timer for 40 to 60 seconds

3. For each square, start the timer, and attempt to draw a different solution in each box

This forces you to stop worrying about the individual ideas, and focus on generating lots of them. It also gets you past the "immediate solution" thoughts you have, and into more interesting ones.

At the end, you can collate the ideas, and pick the best parts from each one.

That's a great trick, I'm going to steal it! I tend to naturally go somewhat depth-first instead of breadth-first, and the quality of my idea generation often depends on how much working memory I have, and how big is the canvas on which I put my notes (I really like my infinite virtual whiteboard on my sidearm computer).

The split also applies to developing code. I've learned to switch quickly between two modes: I either focus on typing code, or on architecture/design decisions. When I coding is getting hard - I feel lost, unsure about what to write - I switch to design mode. When I feel I have something conceptually sound and my brain doesn't want to generate more ideas, I switch back to coding. This can happen multiple times per day. The point is to be always working in the mode that's easier to make progress in at a given moment.

It's probably an obvious technique to many, but I've worked with people who struggled with making these switches - they tried to power through coding even though it turned spaghetti, or considered "design phase" to be something Big to be done seldomly and up front. But it's wrong. The mode switch isn't a big deal - preserving the context in your head is. I solve that by writing down any outstanding thoughts before mode-switching. Often as a string of //TODO //FIXME //NOTE in code.

What is a sidearm computer? How do you manage your infinite canvas?

It's how I call the computer I use in situations when I can't use my primary computer. E.g. on the bus, in the bed, while going for a trip. My primary computer is a powerful desktop machine, and I pick the supporting computer to be light and mobile, but preferably powerful enough to handle sophisticated tasks on its own.

(This is through analogy to a soldier, who carries a primary weapon - perhaps one that's heavy and unwieldy, like an anti-materiel sniper rifle, or one that they can't move by themselves, like in artillery teams - but is also issued with a pistol as sidearm. While having limited range and lethal power, a sidearm can also be grabbed, aimed and discharged quickly, and can be carried and used in situations where the primary weapon cannot.)

My current sidearm is a Dell 5290 2-in-1, with a stylus. Basically a cheaper version of Microsoft Surface. I use a vector drawing app called Concepts[0], which offers an infinite canvas, and is streamlined for use on tablets with pens. This is as close to a good whiteboard experience as you can get on a computer - you draw as if on paper, and then freely pan/rotate/zoom the canvas (or your drawings).

I don't really manage my canvas, I just keep the app open, make drawings and notes and diagrams, and occasionally sort them into "galleries" when the main screen gets too crowded.

[0] - https://concepts.app/en/, has versions for Windows UWP, Android and iOS.

> "(I really like my infinite virtual whiteboard on my sidearm computer"

what software do you use for your infinite virtual whiteboard?

EDIT: whoops, just saw my Q was redundant; thanks for responding to the other comment

https://concepts.app/en/

I keep a running project journal in a google doc with to-dos and just stream-of-consious thought about the problem at hand. If I have an idea for something that's not a current priority, I put it in under an out-of-scope header. I can come back and collect it later when I'm in a big picture planning phase and it lets me stop carrying the mental weight of "I want it to be perfect" that leads to paralysis because I can't implement everything all at once. Writing down my thinking helps recover from interruptions, which are frequent with kids underfoot.

Reading these comments has me asking "Does nobody use whiteboards anymore? Do they just start coding?"

I've used that method, too, with great success! Are you familiar with design sprints[0]? I think I learned it from there. FWIW, design sprints are a really good method to find a solution to a given issue in a decent amount time[1] (not too slowly but not too fast, either, as to not overlook alternative, superior solutions).

[0]: https://designsprint.org/

[1]: Those 4 days they mention on the website can often be reduced to a day or two once you've already done the sprint in the same problem area a few times (and provided you're tackling a small enough and specific enough issue with your sprint).

Serious question: why use a tool like Figma that can capture so much detail? Don't you feel like it's implementing it twice? As compared to a napkin sketch that lets you see the detail you care about, but without less fussing to get just the right widget everywhere.

Or do you just not go the full distance a design-only designer might, and do more of a just-the-critical-stuff approach in Figma as if it were a sketch?

I used photoshop for this level, kinda specifically because it's not intended for this and I can't take it too seriously. I fiddle with and position the art, add some text boxes, etc, and squint a bit to see how it looks in broad strokes.

When and how do you transition from thinking/marketing/etc. to building?

And how do you handle situations where:

(1) you know you must ship, but it’s not good enough?

(2) you know you must think/market/etc., but you’re building?

I'm the most dysfunctional wannabe founder ever, so I am 100% not qualified to answer this :)

With that said, I think product/solution ambiguity is rooted in confusion about the problem being solved. It comes from starting with an idea, and not a painful problem that people already experience. Alternatively, from a problem that exists, but is incredibly ill-defined.

It would be disingenuous for me to comment further, because I'm still learning! My view is it's easy to create a solution, but really hard to find & well-define a really painful problem.

My biggest problem is thinking instead of building.

I’ve had and still have some great ideas, and that’s all they amounted to thus far.

When I’ve started to build, I get stuck spending a lot of time to produce very little, because I try to implement a novel way to do something simple that no one would want while deploying it easily and handling requests quickly.

My greatest dream is that I write something eventually that actually works and that people would want to use.

My greatest fear is that either that no one would use it, because I don’t need it or understand the need for it, or that it would work, not scale, and I’d have leveraged everything and let everyone and myself down.

Also, execution bores me. It’s more fun ideating, thinking and analyzing, but I’d like to be responsible for creating things that are interesting and solve problems or make life better.

I’m unsure where the risk-averse creative fits into a startup CEO role.

Your fear assures your fate.

Accept that is the case and let yourself code anyways. Then you may end up being surprised by what you can accomplish.

A lot of it comes down to being intentional. You can only fit so many features (functional and non-functional) into any given time window. So you are either selecting the features and allowing the time window to expand to accommodate it or removing features to hit the window. There can be some negotiation for sure, but those are your levers.

I think staring this fundamental truth in the face goes a long way. Very few projects can allow the development window to expand indefinitely. A startup needs customers and feedback, even if only for another funding round. An established company generally has deadlines driven directly or indirectly by customers. Both can slip a little, but not indefinitely. Not all features are strictly necessary. So you optimize for time and importance.

The hardest thing to get over is that you will never think it's good enough because it could always be better. But existence is a feature. The ultimate feature. So you'll have to ship an imperfect product and iterate. Experience usually gives better hand-holds on shipping something.

I also tend to find that half-features please no one. You're better off either finishing something or cutting it.

I feel that. Writing code and zooming in on individual tasks is much more my jam than zooming out and seeing the whole picture.

At my current job I kinda have to do all of them, I'm the solo developer on the UI of our application (my colleagues work on the C runtime, the UI generates configuration for it and shows diagnostics and statistics data). What this project really needs though is more people working on it, and the way things stand I'd be in the lead there, so I have to take a step back from the nitty-gritty.

This level of knowing oneself is gold. The older you get, the better you get at managing your self and your (sub-optimal, emotional, human) tendencies.

When you are young you may think that you can just adapt to anything (I did). But you often can't. You will be lazy, procrastinate, feel like you deserved a relaxing day, get cranky for (un)known reasons, etc. You will have emotions, and they are not rudimentary things you can ignore because the annoy you from time to time. They are you and they need to be listened to and understood.

This is what experience is to me: Getting to know yourself and riding your own waves of enthusiasm and productivity and knowing when to stop and reflect or seek help or when to accept your shortcomings and move on without shedding tears. To know when you are fooling yourself and know that you will get disappointed in yourself and will develop negative emotions and learn how to avoid that by being more realistic about your abilities (and time management skills).

More an more I accept deep down that I won't be the next president or the next Steve Jobs even though my parents told you I could do anything I set my mind to! And I know that that is ok.

Great insights.

> parents told you I could do anything I set my mind to! And I know that that is ok.

Well that truism only misses nuance, it's really true you can/could/will do anything you want, If you do believe in free will after all.

I would just add the stoicism on internal/external locus of control.

IMHO the part parents mostly miss, is you cannot control how others, as in other humans, society, et all, will react to you/your actions/your creations, or if you will even be noticed or not before you're out of the game...

Just look at all the bullshit some scientists, artists, businessmen, etc or anyone trying to challenge the status quo, had to go through just for the mere fact that their ideas didn't match those of their time...

I've been struggling with something similar, although I think that in my case it's tunnel vision and the impostor syndrome.

I often get completely lost in the minute details, and find it really, I mean, really hard to move on to more important things in the bigger picture.

Then, just getting stuff out and sharing it with people becomes a chore as soon as I'm done with the more difficult parts of work.

Things I've tried:

- follow TDD and XP, Design Thinking/HCD (iterative methodologies that allow you to slice problems differently, split them into smaller chunks)

- Build smaller products/tools (most of my apps are really, really tiny, an old example: http://facade.photo)

- Build a tool to separate writing from editing (https://sonnet.io/posts/ulysses/)-I've been using it every day for the past 1.5y

- Force taking regular breaks, even if I'm focused, to regain context (pomodoro)

- therapy (I got to the point where building a calculator in JS took me a week, which made me realise that maybe there are some deeper problems at play here)

I was at the point where I would run courses on having this high-level perspective: XP, pairing, workshops on Human Centred Design, and ironically, I find all of that paralysing in my solo work. So, I guess the last point from the list (therapy, taking time off) seems to be the most helpful one. I still find all of that extremely frustrating, almost destructive.

Side note: either Clean Coder or Pragmatic Programmer criticises being "in the zone"/the state of flow precisely for the reason you've mentioned. I recommend reading both, although I think the approach to the craft they describe is to put it mildly, draconian.

Elon said it well in an interview regarding Starship development, “most common problem in engineering is optimizing something that shouldn’t have been built in the first place”, https://www.youtube.com/watch?v=cIQ36Kt7UVg

Broaden your view. You are not put on earth to write great code, but to solve real world problems. Software development is a means to an end, not the end itself.

Well, Elon and SpaceX has the luxury of having a total control of the product's technical requirement.

Most probably this is because Elon, being the CEO, has enough technical prowess to oversee both the real-world requirement and technical aspect of the product. This allows the company to streamline the practical/from-real-world requirement and the technical specification, therefore eliminating "things that shouldn't have been built in the first place".

This is luxurious because other tech company either does not have and/or does not realize it must procure.

One of my personal daydream is to be in a period where this streamlined real-world requirement and technical specification is common, not a luxury.

Excuses. What organization your work for is a choice you've made. You need to make sure you work for a well functioning one, few things are more important. If you can't get hired by one, start one yourself.

Not excuses. I'm pointing out that to achieve the streamlined real-world-tech-spec, you need that kind of person.

My wish is not only for my organization but for everybody. The world might be a better place if things are cheaper to maintain.

You don't need to be Elon Musk to think hard about if you are optimizing for solving real world problems or something else. It's a habit of mind and the courage to change your circustances if you find yourself in a situation where it's not possible do things the right way (e.g. in a dysfunctional organization).

Relevant similar quotations: https://quoteinvestigator.com/2017/02/09/efficient/

Sometimes though, the engineering exists to create art. Because we are all human and we all in our own way yearn to answer the question "What is beauty?"

Including the folks at Valve.

One of the characteristics of Flow State is

> A loss of reflective self-consciousness

Developers who spend all their time in flow state are not thinking about other people. Worse still, in many cases their emotional attachment to the code they wrote in Flow can be very high, leading to defensiveness and rationalization.

Really any time you write a module someone will take issue with how you did it, so it can be a little difficult to discern if “you do it too”. If you can make most of your decisions outside of Flow, this seems to go a bit better in this respect.

If you get stuck, leave your desk, snap out of it. Think. Which is another way of saying that if you’re going to rely on Flow then you’d better figure out how to drop in and out of it more or less at will.

Yeah; related tangents: I think it was Dr Ben Hardy whose advice resonated best with me: "Always make decisions in your peak energy state". It means I'm sometimes overly ambitious or set the bar too high, but overall it serves me well.

Also, acknowledging and leveraging different modes of thinking: "open" or expansive, broad, associative, free-form on one hand vs "closed" or focused, directed, narrow, deep on the other. We tend to associate flowstate with the latter, but some of the most profound and impactful work I've ever produced has stemmed directly from the former.

So many thoughts here; this topic fascinates me.

I'm on the other end of that curve; I tend towards thinking and mentally mapping / exploring permutations and implications at the expense of build/ship/iterate. I've learned to adopt a bias to action when called for, but it's a conscious effort. IMHO teams with a range of cognitive styles are the most effective.

Engineering and marketing have contradictory value-systems, so it's easier to have them in separate people.

I wonder if separate rooms, with distinct smells, and wearing different hats would ease the transition.

Depends on your lens.

Both solve problems.

Engineering at its worst and marketing at its worst have contradictory value systems.

At their best though, they are as harmonious as art and mathematics.

https://www.youtube.com/watch?v=-vZ_E1OO_PY

I'll elaborate: engineering's value-system is about intrinsic value; marketing's value-system is about extrinsic value.

Engineering is about the thing itself; marketing is about the market. Engineers want the thing itself to be good, by various metrics; marketing is motivated by market needs/wants and competition/alternatives.

For example, coherence and high performance are properties of a product, that an engineer might value. But for the market, a shopping list of properties at good-enough performance, may be what's needed.

OP's "tunnel vision", undistracted by the market, is how the best engineering is done. But of course, maybe nobody wants or needs this - that's the role of marketing.

Typically, engineering is market-led, with the marketing deciding what is to be built and engineering building it. But because engineers can create things that the market didn't imagine was feasible, it is sometimes engineering-led.

Henry Ford apparently said the market would have wanted "faster horses".

Startups ideally exist at this intersection, where engineeing creates things that never were, and marketing creates needs that never existed.

Note startups are often co-founded by a duo of engineering/marketing - because these inconsistent value-systems are easier to have in separate people.

Yeah the plan -> build -> evaluate cycle is a healthy way to ship. I do that too. Monday are my plan days with lots of alignment meetings.

Friday’s are my evaluate days with tons of both customer and internal calls to get feedback.

Tue-wed are my build days. I try to not to have any meetings after lunch. That is my in-the-zone time.

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.

Oh! Delphi was way ahead, at least on the user experience, I remember VB6 not having 'undo' actions for form editing so if you sneezed and accidentally moved a bunch of elements in your form, well...

And don't talk about VB redistributable, that weren't funny at all in the dial up era...

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.

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.

Build stuff with care and craftsmanship. Strive for excellence, take pride in your work and deliver, not ship.

You nitpick, therefore you are not cool.

I am not a fan of the term “build”, similar to “deliver”. I’m more of a “manufacture” and “bring to life” kinda guy.

I like those better. Craft is great as well.

I like “unleash”

I prefer "expose", as in "expose to radiation" - it connotes long-term suffering of the users of my work.

Or perhaps expose as in emperor has no clothes!

My software does both!

Steve Jobs popularized the phrase “Real Artists Ship.” He was also famously obsessed with craftsmanship, especially of the parts that weren’t seen by users.

https://thenextweb.com/apple/2011/10/24/steve-jobs-obsession...

It's so nice to see this article, and wonder what Apple was thinking when they were deciding what material to use for the insulation on their Lightning and (old) MagSafe cables.

Original Apple cables seem to suffer from the insulation flaking over time — and Genius Bars all around the world (I've tried, many times) refuse to acknowledge that it's a manufacturing defect.

You can build something that is excellent, yet if you do not ship it, it will have no impact. Shipping to me is bringing a technical feature or increment to customers' hands. It is a product, yes. You sell it, true. There is nothing wrong with that if you are solving a problem or removing a pain.

I’ve always thought the term and colloquial meaning in tech arose from the need to act on delivering, otherwise one could focus on craft almost perpetually.

No, I remember what it meant. Once you put a product on a ship and watch it sail away, you can no longer tinker with it. You might not feel finished, so it takes resolve. Finished or not, when it sails away, you're done.

Back when software was treated as a physical packaged good, it had to physically leave your "factory" by a certain date to qualify as a sale during the quarter, allowing it to be claimed in a quarterly income filing, which would boost the stock price and, thereby, the compensation of execs and employees. So, the sales team would sometimes have to carry an armload of shrinkwrapped boxes out the back door into the parking lot to claim a sale for that quarter. It had legally "shipped". The programmers (former high school nerds) would be desperately hanging on to the code until the last possible minute--there was always more that ought to be done--while the sales team (former high school jocks) would be forcing the programmers to "hand over that disk, now, nerd!"

No courage was required by the sales team to ship. Their job was just to book the sale. In the parking lot by midnight? Hello sales bonus. But real courage (or threat) was required by the programmers, who would be forced to let go of code that could not be fixed "thru the wire" in those days, knowing that they would be blamed for every flaw that they "shipped".

Oh I remember when video games used to be shipped in that they had to finish everything. No patches later. It’s going to get burned on the ROM and off it goes sailing to their customers.

Now a days, shipping to me evokes “Fuck it, ship this shitty MVP to customers because ship ship ship” and then they wonder “Gee, why didn’t my app take off?”.

I understand the need to ship, but I never see anyone daring to challenge the frantic broken shitty app philosophy and maybe wondering if they built them with care, maybe... just maybe customers with actually come? Has anyone tried to go against the grain since the SEGA days? It’s high risk.

Thanks for a great perspective.

As a counterpoint, I've a janky product that I've soft launched. It's definitely a rough beta. But because of churn on the underlying platforms it'd be a constant, full time battle to polish out all bugs. Even then some quirks may never be fixed because web extensions aren't technically meant to allow interrupting all means of browser navigation.

And for me it's all a (sometimes not so) fun little side project. If I had never launched at all then it's possible no one would ever get the benefit of my unique feature.

There are similar competitors which I'd rather just buy and use, yet they don't have the one killer feature I wanted.

Exactly. I see a beaming and anxious engineer standing at the railing of a wharf, watching a cargo ship slowly and unstoppably glide away to a distant port. As the engineer's scarf flutters in the wind she looks down at her trembling hands, hands detached from their creation, hands with energy and nothing to do, hands that slowly acknowledge the building phase is over. Now it's time to evaluate.

If you change the metaphor a bit "ship" sounds good. Except instead of putting the product on the ship, the product is the ship, and once you've shipped out you now have to maintain that ship with no land in sight, supplies running low, and the crew grumbling mutiny.

This is what cripples most indie hacking projects. The idea that if you build it well enough the customers will come to you.

Right now, you need more selling than ever to get found and heard. Put this in perspective, even if you went down the low-touch, organic selling route of content marketing and you were building a MarTech product. You would as of my last check be competing against 2000+ MarTech SaaS all effectively blogging to the marketing department, every week. You then could switch to advertising but again, there's probably 200+ platforms already in your product area.

Slow growth is the best growth, technical debt is minimized and you can call the customer directly to learn from them what they like and dislike. Which is still considered selling and unless you 'ship' you get no feedback. I feel like people are too focused on the 'meaning' of words when really, it's sink or swim when most products launch.

I don't feel the same way. I feel that "ship" feels like a larger scaled "deliver", while "sell" feels more focused on the transaction rather than the product.

The evocation of image of frantic developers churning away might be coming from your previous experience working at or reading about that shipping culture. Unfortunately, I am exposed to that chaotic shipping culture too. I feel this disastrous shipping stories is everywhere, enhanced by the nature of software development that gets more social each day.

At the end, it is the bad practices that leads to bad shipments that we must resolve. I'm comfortable to keep the original meaning and feel of the word "ship" to separate the bad practices from it and acknowledge them as problems -- the first step of a problem resolution.

> 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.

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.

Shipping something does not mean you finished something.

And not finishing something means you do not necessarily understand what you shipped.

> 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

IMO nothing came close to Visual Basic from that era. It really was a GUI builder IDE all in one.

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).

IMHO Delphi was in some ways a better VB than VB itself.

> Bill was wearing the same presenter shirt we all had to wear.

Can somebody explain?

all presenters had to wear

I'm pretty sure he didn't mean everyone had to share the same red shirt, passing it on between presentations.

I for one would not have liked to wear it after Ballmer.

This is something that MS makes you do when presenting at conferences (it a uniform rather than the same actual article of clothing of course)

Scott Guthrie's red polo short always made me chuckle, he wore it without fail on stage. And then at one conference the whole audience turned up in the same red polo.

reminds me of a joke; Renes Descartes walks into a bar. bartender asks him "a pint, Sir?"

Descartes answers "i think no-" and promptly disappears.

Negative, I am a minimum viable popsicle.

Reply on news.ycombinator.com