Joel on Software

Sorry, Prashant, you lost track of the plot of the story somewhere along the way.

(creator of FogBugz, here)

FogBugz won and Jira won, but they were playing different games.

I wanted to make software development better for programmers. When I started creating Fog Creek Software in 2000 programmers were treated like typists. They were not paid very well (my starting salary was $33,000). There was almost no thought around how software should be developed. Companies that scored high on the Joel Test[1] were almost unheard of.

The LAST thing I wanted to do was make another tool of oppression for management to impose gantt charts and deadlines and strict rules about who has to sign off on things.

I set out to make software development better for programmers by blogging[2] and by building a company that would be a great place to work[3].

In 2000 the only way to do that was to bootstrap it. With a team of four people we couldn't build anything complicated. We started with bug tracking software because at least we could touch one aspect of programmers' lives with our philosophy.

FogBugz was designed for smaller collegial teams of people that wanted to work together effectively and needed a clean and simple way to track issues using the smart workflows that small, professional teams like to use.

It was remarkably successful and profitable from 2000 to today. We've never stopped working on improving it, but we also have never abandoned the market of small collegial teams of…

I graduated in December 2001, with a BS and M.Eng in CS from a well known school. This was almost precisely the low point after the dot com crash. I spent 4 months at home with my parents doing nothing. I had some random uninteresting interviews; the most interviewing was for JPL in Pasadena, but it wasn't a fit. Then I managed to find a summer internship at EA in April 2002. Not even a full time job.

The game industry was the only thing in software "going well". It's completely decoupled from the web/dotcom business. I think EA's stock doubled from 2002-2004 because everything else in tech was completely stagnant, at least business-wise.

I moved to Redwood City first, then SOMA later in 2002. SOMA was completely different -- sort of tumbleweed-y as someone here put it. My roommate from craigslist was 5 years older and worked at a company in San Mateo, but otherwise I met almost no other tech people.

Everyone I knew from college said they wanted to move out to California, but not many did because they couldn't find jobs (although most of my college friends were not in tech).

I did have a college acquaintance who started at Google in 2002, and I found that interesting because I had used Google since summer 2000, but not noteworthy as far as I can remember.

After that summer internship in 2002, I converted to full time at EA for a $60K salary. That sounds ridiculously low now!

In 2003, I was sick of my job at EA, but I wanted to stay in SF. The only decent…

I think you are confusing marketing with advertising. What you are doing IS marketing. Marketing is about understanding the market’s problem you are solving and figuring out ways to connect those people with your product.

A great way to market your product is to use “content marketing” where you create truly useful information on how people can solve their problems that may or may not even need your product to work. This combines being altruistic (they may read your content and figure out how to solve their problem without your product, and that is ok) with being business savvy (they may be so impressed with your knowledge and articulation that they want YOU to solve their problem, so they hire you/buy your product).

Advertising is just one very small aspect of marketing. A really good marketer understands this and finds the best way to expose their product and reach customers that really need your help.

Probably one of the best examples of altruistic content marketing was Joel Spolsky.
https://www.joelonsoftware.com/

He never even tried to sell his company’s software FogBugz, but the exposure FogBugz got through his blog was so much greater than he ever could have gotten through advertising. He created a reputation that eclipsed his product several times over. You don’t have to go to the length he did, but hopefully you get the point.

Joel on Software is a classic: http://www.joelonsoftware.com/
Sadly, a few years ago he mostly stopped writing about business and architecture, but the archives from around 2000 to 2005 are really good, and mostly timeless.

infoq.com has lots of good articles and talks, some language- or technology-specific, but most with a focus on architecture.

The O'reilly Head First books "Object-oriented architecture & design" and "Design patterns" are somewhat basic, but an excellent and accessible start.

For something deeper and harder to digest in book form, try some of the classics like Eric Evan's "Domain-driven design", or Martin Fowler's "Patterns of Enterprise applicaton architecture".

As for some specific styles, try typesafe's manifesto and description of reactive applications, Hohpe's "Enterprise Integration patterns" for pipes-and-filter architectures, and anything by Stefan Tilkov (https://www.innoq.com/blog/st/) for REST.

browsers will display invalid/corrupt images (best effort)

tried it right now - took a PNG and a JPEG, opened them in a text editor, literally deleted the second half of the file, saved, and dragged them into both Firefox and Chrome - they are displayed instead of erroring out.

there is a classic article why a minimal version of the web with features removed will fail - you removed 80% of the features that YOU think are not important. thats a classic fatal mistake

search the web for different proposals for a minimal web and you will understand - they will have removed some feature they think is bloat but which you kept in your proposal because you consider it critical. which is why you created a new proposal - their minimal proposal is not the right one for you

https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/

This is a classic debate in programming, literally:

2001: "Beating the Averages" (Paul Graham) [1]

2006: "Can Your Programming Language Do This?" (Joel Spolsky) [2]

Both of these articles argue for the thesis that programmers that have been deprived of certain language features often argue that they don't need those features since they are already comfortable working around the lack of said features.

It's a fancy way of arguing: you don't know what you're missing because you've never had it. Or, don't knock it until you try it.

Consider, is your argument a) I've never used it and don't see a need for it, or b) I've used it before and didn't get any benefit?

1. https://paulgraham.com/avg.html?viewfullsite=1

2. https://www.joelonsoftware.com/2006/08/01/can-your-programming-language-do-this/