Part I

Mostly you don't need and don't want a 'technical co-founder'.

Also, the concept of 'a developer' without being a lot more specific makes little sense.

Here's the situation:

(A) You can go to college and study stuff and learn, say, (1) getting good at reading for comprehension and writing clearly, (2) the precision, discipline, and tools in pure math, (3) some topics in 'computer science', and (4) thinking 'critically', that is, accurately putting candidate ideas into the correct one of the three buckets True, False, and Not Clear Yet.

(B) You can learn how to do the programming you need for your project.

(A) can help with both (B) and your project, but it's likely quite possible to do both (B) and your project without (A).

For (B), what you need to know about 'development' is what you need for your project.

Here is a fact of life in Computer-World: The world is like a hardware store the size of Texas and packed floor to ceiling with tools. There are LOT of tools. Each tool takes time and effort to learn to use; the main problem is that the tool builders are just awful at describing their work; if you have the usual advantage in verbal skills over male computer nerds, then the documentation may cause you to yell and scream in outrage and agony.

The best technical writer is God, usually better than the pure mathematician P. Halmos. Way down on Earth is D. Knuth. All the rest in computing are in the infernal reaches.

But, for anything very complicated you might need to do, there is likely a good tool for it, and it will nearly always be easier to learn to use the tool than to do without or build your own.

So, most of what you need to do to be the 'developer' you need is just to learn to use some good versions of the tools you need.

Yes, now largely the software you need to write is just a little 'glue' joining together the 'blocks' that are the tools you use.

Can a 'developer' learn all the tools in that big collection the size of Texas? Not a chance! Heck, even being a 'librarian' just cataloging the tools would be more than a full-time job.

Further, the collection of tools keeps growing, quickly.

So, here's a deep, dark secret ALL, REAL MALE HACKER nerds keep to themselves (and never but NEVER tell women!): At the start of each new project, it is necessary to learn at least some new tools.

So, really, NO developer is ready to 'develop' without learning some new tools.

So, one of the main differences between you and any 'developer' is that you just have more tools to learn.

Next, you will need some basics: So, you will need a PC, at least reasonably current. I built mine from parts five years ago, and it's still fine.

You need to get good enough to send and receive e-mail and to use a Web browser. Since you are already posting on Hacker News, apparently you've got this part done.

If you don't know Computer Parts 101, then have someone give you a 30 minute lecture. The final exam will be to go to Tom's Hardware Page and Tiger Direct and explain what you are seeing.

For a Web site business (common now), you need to know Internet and Web 101. Again have someone give you a 30 minute lecture.

Next you need to get started writing software.

Here you should pick between the world of Linux and the world of Windows. While Linux is likely more popular on HN, I recommend Windows if only because there is a company behind it with some tens of thousands of programmers, is a CEO who commonly yells and screams, is a COB who remains one of the sharpest tacks in the box, is about $40 billion in cash in the bank, are some very serious enterprise customers that mostly are pleased, is a LOT of free software (really, after you buy a copy of Windows, darned near all the rest of their software is available for free in 'Express' editions -- yes, where you spend your time and effort learning their software so that you can use it in production and then pay the big bucks), they work HARD on documentation (they should work much harder), and there are so many people programming Windows that for nearly any problem you encounter many others have been there before you, and a Google search can turn up a forum with answers.

One of the best things in computing is Microsoft's .NET Framework. So it is a collection of relatively low level software tools, maybe the size of half of Texas, to do nearly anything more than two people have ever needed to do. .NET is enormous.

Next, heavily your 'development' is to exploit .NET, and for that you have mostly just two good alternatives, use the language C# or use (the more recent version of) the language Visual Basic. I strongly prefer Visual Basic because it is much easier to read on the page and lets you do very nearly as much as C#.

For C and C++ -- f'get about them on Windows now.

Part of .NET is ASP.NET where ASP abbreviates 'active server pages'. They aren't very 'active'. Really ASP.NET is just a way to write software where you mostly don't have to work much with lower level things like HTML and JaveScript. For nearly anything standard in Web site development, ASP.NET has tools to make the work easy. E.g., for a lot of what is needed, it's necessary to write JavaScript code, but ASP.NET does that for you. Nice. You may be able to make a lot of use of JavaScript without ever seeing it.

There is also ADO.NET where ADO abbreviates 'active data objects'. They can be somewhat 'active', but I mostly avoid depending on that. ADO.NET is how in a program you manipulate the database system SQL Server or one of its competitors, Oracle, DB2, etc.

SQL abbreviates 'Structured Query Language' which is closely associated with database.

What is 'database'? Since the work on 'relational database' at IBM and U. Berkeley in the 1970s, mostly we store important data in a relational database. Microsoft's version is SQL Server. A database remains conceptually like some stacks of paper forms say, from the IRS.

So a 'database' consists of some 'tables'. Each 'table' consists of rows and columns. In one table, all the data is for just one IRS form, say, Form 1040.

Each row is like one copy of an IRS form, that is, has the data from just one copy of the form. Each column is like one of the 'fields' on the IRS form for that table.

You can designate a column as a 'key' which is like an 'index' which means that, given a value of the key, the software can read the row with that key value quickly. In the case of IRS Form 1040, one column may be SSN; you may designate it as a key; and then you can regard the database as a stack of Form 1040 copies sorted in order on SSN. Simple enough.

A table can have at most one 'clustered key' in which case the rows are stored on disk in essentially key order, and that can make some operations faster.

Whatever you may do with relational database for a Web site, if your business gets significant, then almost certainly you will store all your routine business records in relational database.

The main idea in database 'design' is for the keys and the other columns to be in 'third normal form' which means that each row is conceptually, in the problem being solved, 'a function of the key, the whole key, and nothing but the key' -- think about this a little and you will see why.

Part of the glory of relational database is 'transactions'. The key here is the 'log file': For each 'transaction', which is just some sequence of database operations that you say are all part of some one 'transaction', the operations are written 'provisionally' to the log file and to the database itself. At the end of the work of your transaction, there is one more 'atomic' write to the log file saying that the transaction is done -- 'committed'.

So if the computer goes down, when it comes back up the data base software first reads the log file and 'undoes', 'rolls back', all the transactions that were in progress but not 'committed',

The classic example is moving money from checking to savings: If the bank's computer quits, then once the computer is running again, the money has either been moved or has not been; there is no case of the money being lost 'during moving'.

Another part of transactions is 'integrity': So there can be many programs running at the same time manipulating the same database.

E.g., while you are moving money from savings to checking, the bank can be updating your checking account, and nothing gets confused. To make this work, relational database has to work with 'locks' and 'deadlock' detection and resolution.

The simple case is two programs, A and B, that both need to manipulate data X and Y in some careful way. So, program A gets a 'lock' on data X; program B gets a lock on data Y; program A then waits until it can get a lock on data Y; program B waits until it can get a lock on data X; and now programs A and B are in a 'deadlock' since neither can complete and will wait forever.

Relational database detects such deadlocks and resolves them. E.g., program A may have its work on data X 'rolled back' and its lock released; program B is allowed to run and finish, and then the work of program A is just restarted.

Nice.

In particular, yes, it is standard to backup a relational database while it is running.

Mostly manipulations of relational database are done with the language 'transact SQL' (T-SQL). So, even if you are using ADO.NET, what goes to SQL Server is T-SQL. You can run T-SQL statements just by typing them into a file and giving it to the SQL Server program sqlcmd.exe -- I like doing that.

For SQL Server, there is a level lower (closer to SQL Server) called 'Server Management Objects' (SMO) you can use in, say, Visual Basic.

You now know Database 101.