This model for a position statement can be helpful in very early development. Having a statement early, even before the solution exists or is even fully understood, will be a competitive advantage. Some of the other examples in comments (which are great by the way) require having a better understanding of what you are building.
> In terms of what comes first, product or positioning, Jackson suggests that the two should grow up side-by-side.
Using this as a model gives you a first cut, which you can later refine and shape into something even better.
It doesn’t make sense for generalized scripts that automate routine tasks. But for some maintenance, build, test, or deploy scripts that only ever perform a specialized job from a single location, it could be handy. I appreciate that Maciej provided it. Always easier to remove it than have to go find it yourself in the odd script you might need it.
Not unlike Goldilocks sampling the bears’ home, what is just right, is often a matter of perspective.
A developers education, experience, and domain all impact how different abstractions are perceived. Sometimes having an abstraction can reduce cognitive load. Think of the configure vs convention arguments for frameworks. Knowing how to implement simple functionality the “right way” (within the paradigm of that abstraction) can make building software easier especially when collaborating with others.
I personally find consistency more valuable than having the perfect level of abstraction. Consistency, even if slightly more or less verbose than I might otherwise choose, means I spend less time thinking about the abstraction itself. It allows me to focus on the problem domain, which is where customer value exists. It has the added benefit of simplifying collaboration with others who are also familiar with the abstraction.
Amazon has a similar offering called Secrets Manager which can be used for sensitive secrets as well as configuration values.
https://aws.amazon.com/secrets-manager/
Immutable ledgers (blockchain) and GIS (mixed systems) and search indexes (elastic) all come to mind as more niche databases. Some of these uses can be modeled in a variety of engines.
Nice to see someone who actually created a large volume site discuss their learnings vs. theoretical works discussing how stuff (c|s)hould be done without real experience.
I can't find the source for the quote, "we still need legislation for blocking foreign websites." The referenced document doesn't actually say that, in fact, the word "blocking" doesn't even appear in the document at all.
Seems like the author of the petition assumed the reader would thing tl;dr and just assume it was accurate.
Great post! Nice to see others are looking at the long term plays and building great products. The post was refreshing to read and validates much of what I experienced over the last year building my apps.
As a fellow Facebook tab provider (My Tab) I feel your pain. I'm concerned about how SOPA and ProtectIP will impact this class of service as it would be impossible to police all content added via tools like ours. It's already been said, but you can run your own DNS or even contract for DNS services from a wide variety of places. I would move your name and SSL certificates to a trusted registrar ASAP. Glad you were at least able to work around the issue by pointing directly to the app.
The language you use is largely irrelevant - it's the team you work with. If you want to work with the language du-jour you should find a founder who is fluent with that language.
If these are the technical founders you want to be with - then you should let them decide.
1) Architecture. Understanding what the actual hardware is doing when you walk through a program. Knowing this can help answer questions like: Why does a variable go out of scope? When a data file might benefit from an index.
2) Algorithms. Learning the math behind why one approach is significantly faster can change the way you think about solving problems.
3) Approach. More advanced thinking around handling information. Why might you use a btree vs a linked list etc. Can I achieve the same result using less memory?
Curated newsletters are only as good as the curator. If you are going to crowd source the curation, even allowing multiple curators per topic, you should allow the readers to also rank the curators. You could do this passively in the email through analytics or more directly with a direct response, such as HN's up arrow.
You should most certainly give credit to the curators! I would also include a digital nanny to remind them periodically to prepare a newsletter. It's easy to forget those sorts of commitments if there isn't a direct reward attached to it.