Three years ago, I was the sole employee/founder of my startup. Today, I'm CTO of a 21-person company with a 6-person dev team.

As an individual developer, my default loop is "Find something to do. Do it. Repeat."

As a CTO, my default loop is "First, cycle through all my employees and make sure that I have equipped them to be happy and productive in their jobs. Second, find something to do. If possible, delegate it; if not, do it. Repeat."

Well...I've been in the software engineering biz for a while now and go between being an engineer, an architect, and manager depending on the company and group. I don't have any formal management training and don't even have a post-high school degree. But I love building software (I started writing assembly on an Apple II+ way back when) and working with people and am in a constant state of learning.

The quick answer is that there's no easy path if you want to be good at this. You need to be aware of your natural strengths and weaknesses, and what you've built up over the years to compensate. If you can, find a mentor, or at the very least have regular lunches or coffee with folks with more experience.

It sounds like you are a technical leader with management responsibilities, which is a very tough position. A lead/architect position without management duties usually means that you are involved with all technical decisions in the group but don't have direct reports. When I'm an architect, I expect the majority of my time will be writing code with maybe 30%-40% of my time split between formal meetings and hallway conversations. I will not take an architect position that has no hands on coding - it's a recipe for failure. An architect/lead will need to understand the business and technical needs and help drive things forward so both sides are happy. Look for quick wins here to keep things moving and 80/20 solutions. Also know when to stand your ground on things that you know are wrong - be able to communicate your reasoning for both engineers and non-technical folks. That role will also need to have strong technical vision and the ability to communicate that vision so other engineers will be able to follow the path. Figure out the types of engineers and what they need to get their jobs done - some like diagrams, some like talks, some like code examples, some just need a few lines in an email. Conversely, you'll need to be able to help the business side understand the technical side. You'll also have to know your team and help with things like pushing things through to avoid engineer navel gazing, balancing NIH attitudes, breaking ties on proposed solutions, slotting in engineering driven changes that destabilize things, helping the engineers understand why they can't rewrite a key component of the system without showing the business value, helping the business understand why adding a fifth story to their building won't work because really have a bicycle, etc.

Architects are expected to be "big dawgs" in terms of technical skills, so it's ok to be opinionated and try to out-think others. Your own style will come into play and you need to recognize it and be ok with how you work - you might be the type who doesn't suffer fools lightly and because you see the solution before anyone else, you just make your vision happen and ram it through. Or maybe you have a high end team and you need to listen to the other ungodly smart people around you and do more consideration. You do need to pay attention to other engineers and business folks, and listen to them.

A good manager requires an addition set of skills. Management is really a career restart because you're really going down a whole new path. The things that got you to the management position aren't the things that will make you a good manager. Being the smartest person in the room does not a good manager make. A good manager creates an environment for others to succeed. A good manager listens a lot and doesn't try to come up with the solutions. A good manager recognizes that the right idea will present itself because the team is awesome. Try to come up with as many options at possible decisions points. If a tiebreaker is needed, a manager should be able to argue both sides convincingly and not take sides (unless one side is just flat out wrong, but hopefully it won't come to that). A good manager will let problems and solutions come up from the team. Managers need to be aware that each person is different and adjusts to each person. Depending on the group, they also need to have a slightly more balanced view of the business then an architect. It does require some politiking as well - you shouldn't go into a meeting for a big decision without knowing where people stand ahead of time. Managers also have to deal with the 'kindergarten' issues like ruffled feathers, misunderstandings, bruised egos, etc. You'll need to know when someone is just venting versus needing your action. And people have lives that impact the team as well - people get divorced, have kids, get sick, have people die on them, switch genders, come out of the closet, find Jesus, etc. A good manager makes a personal connection and gets to know each person's story. This lets you figure out where each team member is coming from and then how you can make sure their needs and values are met at work. People are happy when what they want out of life lines up with what the company needs. Managers need to know when someone on the team is causing issues and maybe isn't working out. Letting someone go is tough, but usually it should be obvious to everyone involved that things aren't working out. It also involves bearing bad news to both your team and other teams. Telling the CEO that your team fucked up and caused customer level issues is rough.

Let's see...what else...hiring the wrong person is orders of magnitude more difficult than delaying a hire. Be super picky when hiring, even if the executive staff is pushing you hard to fill those reqs.

Engineers like to solve problems, so presenting things in the form of a problem can be a useful approach.

Even if you have a solution in mind, start from the top and lead people through. Let them come to the same conclusions you did and when they do, them tell them the pros/cons of each decision.

Sometimes you have to be the alpha dog and make a decision that someone heartily disagrees with - you need to understand their position, be able to echo it, and stay the course.

You cannot take on other's emotional issues - you can be aware and offer help, but you can't internalize them.

Try not to play favorites - this is tough because you'll find people that you connect with easier.

Put yourself out there, let the team get to know you as a person so that connection is better.

You need to keep in mind that you might have to fire anyone on your team at some point, or give them feedback they don't want to hear, etc. So there's a fine line between becoming friends with folks and being their boss.

Have fun with it, I try to keep a sense of play with me because that's part of who I am.

I dunno - that's it for me - this was kind of a lot of stuff without much structure, but I wish you the best of luck. This is a tough change for an engineer but the fact that you're asking these types of questions shows that you care and are willing to change to be better.

I made a similar transition myself and have one piece of advice for you.

Forget about all that "leadership" and "management" bullshit. Seriously. When you have direct reports your primary function is to serve them. I'm not kidding - I know it sounds all squishy and kumbaya-ish but if you think about what it means to serve somebody else you'll have a really good compass to guide you through your day.

Everybody seems to throw around bits of advice around what to do and even how to do it. The problem is every person is different and since people make up teams, every team is different. Plus, they change. Don't get lost in the what and the how until you understand the why. Everybody on your team has different needs and serving those people means understanding their needs. Some people need to be micro-managed and some people need to be given tons of space. Don't let their needs/situation effect your respect for them and always remember that people change.

Your to "why" will be different than anybody else's answer to that question and will give you immense insight into which "what" and "how" things you pick up from all that advice that is out there. It will also determine what kind of a leader/manager you are. This is important.

Identify what makes you and others around you happy and you will probably find yourself asking "what should I do?" a lot less often. Oh, and in case it's not clear, don't be so naive to think that "happy" is all fun and games and wine and roses and group hugs. And don't forget that you serve the "team" too - it's an entity with its own needs and challenges.

Wow that is a description of me 10 years ago to the T. I was always the guy that people turn to and the guy that pulled the project out. It can and does go to ones head. Be very careful to not become arrogant, I really wish someone gave me that advice 10 years ago.

As for your case specifically, the delegation is going to be the hardest one and the one that you have to cross the chasm on. Given your nature (I know from experience) it will be hard but you just have to trust in your people. Hire people that you believe are smarter than you, this will help in delegation because you will perceive their opinions higher than your own. Also try to remember, you design systems the way you do because it worked for you, they will design it their different way because they are drawing on what worked for them, look at it as an opportunity to learn a different way of doing things. Many times when people like you and I enter this type of role we believe that we are the authority, it can make working with our personality type unbearable when you are a subordinate. Instead take it as an opportunity to learn. Help them make their solutions better, not make your solutions better. Just because you are the lead does not mean you are the best at every situation, be humble and try to be an eternal student, that is the best advice I can give you.

Shortly before I started managing engineers I read "Managing Humans" (I'd already been following http://www.randsinrepose.com/) and found it helpful. One of the best resources I found was (luckily) my own boss. Find others in a similar (or higher) position and talk with them regularly, openly, and candidly about any challenges you're facing.

I wish I had better advice, but what you'll find is that being a good manager/team lead is at least as hard as your old job (and probably harder). Continuing to do your old job alongside it, while probably a good idea for your own job satisfaction/sanity, will only make it harder.

Random bits of advice I find helpful:

* Your primary job is to shield your direct reports from management BS (false priorities, unrealistic deadlines, company drama); while this is less of a problem at a small startup, don't ignore it. Your secondary job is to make your direct reports look good; promote what they're doing and make sure what they're doing is aligned with the company's goals.

* Schedule 1:1 meetings. See Rands' advice on how to structure and run them, but basically keep them short, informal, and regular. Start with a softball and use it as a time for your direct reports to warn you about any upcoming problems that may be bubbling. Avoid the temptation for status reports, one larger team meeting instead, etc. Sit down with each individual direct report and get to know them better.

* Set clear goals and priorities for everyone.

* Avoid the temptation to micro-manage. You may eventually find you have an employee who has to be micromanaged, but most people hate it and will find it counter-productive. While this sounds obvious, it's hard for someone who likely got to their new management position because they were the best at the job they're now managing. Let people make mistakes and then let them recover from them.

I generally think of it this way: a manager tells you what you have to do. A tech lead tells you what you'd be stupid not to do. You won't have much formal authority. At the same time, you hopefully won't be under much formal authority if you chose the right startup.

At the same time, you earn a significant amount of "political capital". People will probably give you a certain amount of deference. And you earn the unique benefit of having a unique perspective on something.

Don't think this can't all be taken away from you, because it can, either due to political or technical considerations. You can get marginalized by someone with an agenda, or you can lose the respect of your peers with a few wrong decisions.

The good news is that you really don't need great leadership or people skills. You just need to convince people that the benefit of having worked with you is greater than the cost of having to put up with you. People are willing to forgive the occasional foot-in-mouth incident or the occasional screw up. You just have to make sure people know what benefits you're providing them in return. And having been objectively right or gotten great results will more than make up for having accidentally hurt a couple of feelings in the process.

A CTO of a very successful startup on the valley recommended me Difficult Conversations[2].

As long as you remember that empowering other people to do great work is very valuable in itself (as it is a multiplier), you can motivate yourself into getting to understand this side of software development.

It is not only important for tech leads, but for CTOs, and open source project leads.

Managing people is easyâ€"but being a manager is not about managing people.

You have to be aware that managing is not as satisfying as coding and your goals have totally changed from now on.

- Learn to listenâ€"that's so crucialâ€"they're tons of techniques to get a better listener. Listening can be boring but these techniques enable you to listen hours (even with a smile on your face) without getting bored. It's so damn important that I stress it again: you should listen 95% and talk just 5% (from now on meetings aren't fun or a relaxing break, they become hard, boring work).

- Always 1-to-1 meetingsâ€"always. Every meeting with more than two people is worthless, try to avoid them, if you can't just keep them short and full of small-talk, fun and non-sense but without decisions. Harsh words, but leading is not anymore about cookie-cutting talks with colleagues. That's one of the big downsides of leading.

- Don't focus too much on your staffâ€"look that they are happy and motivated (most important) and they have always challenging work, that's it. Don't try to be all the time around themâ€"if they need help be there. Don't change your communication, just be yourself, but don't think they are your friends. Focus now on next steps within the companyâ€"you are now doing first steps in management and your work changed from working yourself to networking, to give and take and last but not least to power politics (if your startup is >100 employees). Look that you spend more time with peers from other departments and higher level peers in your company. If you can't progress or your company sucks in less than 12 months, look that you spend a lot time outside your company (there're lots of ways) and move on.

- Don't use tactics or manipulative techniques even if you are good in it. People always feels there's something wrong. Be yourself but keep distance.

- Get a mentor or coach with leadership experience in highly volatile environments, preferably outside the company

- Because working oneself is still most fun, look that you keep coding on private projects, even while in office (there're lots of ways). That's good for your own motivation and keeps your coding skills fresh. Otherwise you burnout after 6 months of all the meetings, mails and bullshit. That's important because from now on you will slowly loose close relationships within the corporation, upcoming relations are different, more political and it's important to stay grounded, meet lot of people (again leave your company often, go to meetups, because there you can just be yourself and that makes you happy; if you don't do this you'll quickly degenerate and get isolated because the working contacts are less and less true relationships). To officially code yourself is not an option anymore (which is sad) because after the first bigger mistake your management will tell your that you are not able to lead your folks when they see you coding with them (which would be better but non-technical management and c-level just don't get it)

These are all only very small hints without giving you the big picture which would take more time and there is no book giving a really deep understanding (I've seen many books before I had my first leadership position, none of them is written by real leaders).

The first thing you need to do is learn the capabilities of your team.

Who are the best programmers? Who are the best programmers for the given types of problems you have to solve? Who are the most creative thinkers? Who is good at meeting deadlines?

If somebody is bad at meeting deadlines, why?

One of the best programmers I've ever worked with was always missing deadlines. Turns out, it was only because he was really bad at estimating time. Once I learned that, and started handling some of his estimates for him, he was the best programmer on paper too.

As for managing, I try not to micro-manage, but it's easier to get a sense of who does and doesn't need it once you understand, from a manager's perspective, who is capable of what, and to what degree of consistency.

For the actual management, most of the time, I would just periodically see if anybody needed any assistance, and let them know that I was always happy to help where needed.

The fact that you're even asking how to be good at this is a really good sign. I wish some of the folks that I've worked under in the past would have done the same. There's lots of good advice in this thread.

My advice is to find a way to handle the pressure from above without letting it affect how you treat your team. Technical teams are built on a tremendous amount of trust and understanding.

If you're constantly getting hammered on by your non-technical boss, try not to pass the buck and hammer your team in turn. You may find yourself in very combative situations with the nontechnical leadership, and you certainly wouldn't want your teammates to feel the same way about you. That makes for a very ugly environment, and most smart people won't stick around for too long if that happens.

Now coming to how might probably go about this is awesome opportunity. Remember a very important thing about software today. Its extremely difficult to do anything big without a team these days. Even giants need teams. There fore I will first start out with both the Technical and Managerial areas you need to be aware of.

Technical:

As a manager, you might not have to know and understand each and every line of code that is out there in your code base. But you definitely need to understand enough technical details to consciously solve problems, take decisions and assign and referee things among team mates when needed. This means you have to on a day to day basis keep track of the developments. To me this can addressed by separately planning a part of the day, this can achieved in a stand up or status call, where everybody quickly reports three things "What they did yesterday", "What they are doing today" and "blockers". Your job is to first get sufficient perspective and context about he work your team is doing, incrementally know their progress every day and remove any thing that is coming in their way of achieving those tasks.

In turn you will have your own updates. Its not difficult with a little discipline. You can take strides.

Management:

Here, you need to take a little care. Planning, Prioritizing, tracking and course correction are crucial. They say, a true appraisal in any company is when the junior and manager know exactly where they both stand. A good appraisal has no surprises.

Talk to your team mates and be friendly with them as much as you can. Develop their trust as a friend. Most people will do work for your just out of politeness and courtesy. Never use provocation or threat as a means of motivation(Often geeks make this mistake). Try to take things as easy as you can, but be serious and stand up and make the person understand the seriousness of their mistakes. Stop there, no further. Basically they must respect you.

Trust them, or at least make them feel you trust them. Even if you don't internally. The reason being once they realize you don't trust them, they will loose all respect for you. They will fail to replicate the same feeling back. Work, productivity will dry out and ultimately lead to a separation.

The best advice I could give is, whenever someone you manage brings you a problem, resist taking it away and solving it for them. Instead, give them some pointers on how they might solve it, but leave ownership of the solution with them. This is hard to do consistently, particularly when it would take you less time to do the work yourself, but the long-term effect is that you grow a team of self-sufficient people, who only bring you problems when they have tried hard to solve them themselves and genuinely need your help. This in turn means your time is freed up to work on the most important things.

You might want to simply look into reading some leadership books. Leadership 101[1] is one you can read in probably an afternoon, to get you started. From there John Maxwell as a few more books on Leadership as well.

As I haven't been in a team lead position myself, I'm not sure if any of these books can help you learn how to delegate as that seems something that would take time and practice.

I have however, worked under a few engineer-become-leaders that are simply horrible leaders, and I -wish- they would read a book like this some day and have it click. Your success as a leader can possibly be measured with how successful you are at raising leaders under your wing.

Do you like your team members? If not, find out why and find a reason to like them. Once you develop that basis to like your team members, everything else will fall in to place. You will take interest in their activities, not just in terms of getting your work done, but in terms of what they are trying to achieve.

Talk to your team members on an individual basis frequently and in an informal setting - people are much more open in an informal setting. Keep these meetings to 5 mins. If there are more topics than can be covered in 5 mins, increase the frequency of meetings, not the length.

Never do your team member's work. Help them in every way for them to do their work, but just don't do it for them.

(Break every rule / advice that people are giving out. Finding what works for you is one of best parts of management)

About not delegating, getting your hands dirty can play to your benefit if positioned right as trying to understand what team members goes through in their activities so that you can make better decisions that are in best interests of team members.

Consider your team lead role as mentoring role and not as a "manager" role. Allow people to make mistakes and do lesson learnt type sessions.

Depending on the size of team, have lunch/ informal gathering as a team and also meet with individual team members informally at regular basis.

Watch patterns and signs in how team behaves around you. If they are quiet around you or always agreeing with you, you have a problem.

Accept that being a lead is going to be challenging. That whatever tasks you have taken on for yourself, you may or may not get to them when you want to. Accept that you will be the bridge between upper management and the technical folks and that you will be dealing with any number of issues.

Also, keep in mind that there are lots of resources out there about how to lead people and be a better leader. Look to the Harvard Business Review ( http://hbr.org ) for some good resources on how to be a better leader.

At the end of the day, as a lead, there is a process that you can follow to help you along. The process includes the following: 1) Meet with your team and work out what tasks are assigned, follow up with each team member and confirm that they understand the assignment by asking them to describe to you what they think they are doing, follow up with each team member on their assignment and measure their progress, and finally, check in with them to review their work and let them know when they are done or have completed their assignment - then start again. Use this process no matter how small or big the assignment is.

Some folks use an agile like approach to management of projects and one of the nice things out of this world is SCRUM and the concept of daily stand up meetings. One of the things I would recommend is to get into the rhythm of meeting with your team for about 15 minutes every day to check progress, see what they have accomplished and see what they are working on for the next day and to see if there are any things keeping them from meeting their goals. If you ever hear a complaint, that is a red flag and try to use whatever resources you have to remove those obstacles.

At the end of the day, you only have so much time and energy. Do the best you can and never loose your cool no matter what the situation is.

One little piece of advice: your priority is giving work to your reports. Avoid at all costs that they're idle. To achieve that, you must plan to be idle yourself half of the time, so you can attend them when they need it (they will.)

The other half of the time is to explain your bosses what your team is doing, so if you're thinking of programming yourself, think again.

Edit: for both halves you absolutely need to know at all times what everybody's doing, how they progress, what obstacles they're finding.

I tend to be of the mind to learn by doing. As many of the others have mentioned, have conversations with your team members and spend time with them. A common practice is to grab lunch with them. This will help you get to know them and become more comfortable talking and listening to them.

I would also recommend regular work oriented meetings with them. Some may disagree, but I think regular meetings to review work, and go over tasks has a lot of value. You will see when they are finishing up their work and be able to hand off tasks more readily. Also do what you can to get feedback from them on you, and don't take it personally when they are critical and learn from it.

Ultimately there is no one answer and you have to find your own style as well as a style that works for your team. A conscious effort and trial and error will be better than books.

Leadership revolves around having respect for your colleagues and believing in them. This component is very similar to an ability to maintain healthy relationships with family and friends.

Don't be just another software developer destined for a career in middle management. Spend quality time with your team and get to know them as people. Find out where they excel and assign responsibilities accordingly. The listening part will then come naturally.

You don't need an MBA. You already know what you need to do. For every conversation you have, concentrate on one thing: being an active listener. Focus on that like you would focus on a technical problem.

I doubt there is one objectively and universally "best" path to learning to program. What worked best for me, might not work well for you at all. In the end, my feeling is that any programming with a (reasonably mainstream) language is a fine choice. And by "reasonably mainstream" I basically mean any language that wasn't intended to be an "esoteric language." So even a less widely used, but still somewhat practical language like Haskell or Ada or Erlang is better than not starting at all.

That said, I think any one (or two) of C, C++, Java, Ruby, Groovy, Python, or Javascript would make a good starting point. All are widely used enough to offer plenty of community and support for beginners, none are so hard to learn as to be especially prohibitive, and all are used in industry and the F/OSS world to a fairly wide extent.

And if you put a gun to my head and asked me to name on recommended place to say, I'd say "C".

Given your situation, I would suggest learning C right now. C is a small language, and will be a good ramp up into C++. A lot of people around here readily recommend Kernighan and Ritchie's The C Programming Language as a book for learning C, though for a beginner, it can be a bit terse.

The good thing about learning C/C++ first is that it will help you understand how the internals work and you will (should) learn how to program efficiently and understand basic algo's and methodologies. For that matter, assembly might be a good start! :-) If you understand HOW things work, it will not matter what language you elect to use down the road (for example, you might want to use Rails because it makes developing web apps a pleasure, or whatever). Ultimately, your choice.

If I were you, I would start messing around with Javascript first. Yes, there are MANY weird things about Javascript. But, the nicest thing about it (for you) is that all you need to start programming with it is a web browser!

Codecademy also has some great simple Javascript tutorials. All you need to worry about now is learning the basics, and the core concepts you learn in Javascript will apply to almost every other language you learn.

In my personal experience, the hard part for a beginner is not the actual programming, but the environment. Fussing with the command line to compile and link a program, or setting up system environment variables, class paths etc. pp. can be a frustrating experience. I would argue that for a beginner a good IDE is an important tool to getting you up and running, having fun and keeping motivated.

I would therefore recommend something highly integrated like Visual Studio C# Express Edition which you can download for free. If you have Microsoftphobia, the alternative would be Java with Eclipse.

Having said that, at one point you HAVE to leave the "kiddie pool" and jump into the deep end. For that I would second the recommendation of Kernigham & Ritchie's The C Programming Language.

first and formost, learn something. don't waste too much time trying to find the "correct" language to learn. Here are three options:

-If you are interested in reading SICP, then learn scheme-If you want something that is a good prereq for C++, learn C-If you want a simple and very useful language, learn Python. You'll probably keep using it in the future

Learning the basics of any (within reason...brainfk,etc not included) is within easy reach of a beginner. The difficulty with languages and C++ is the more complicated features like templates and such.

Every minute you spend researching and trying to decide which language to use is time wasted. You shouldn't be learning languages at all, you should be learning concepts. Figure out concepts like what linked lists are, recursion, inheritance, etc. Then learn the details of some language, then go back to the fundamentals and realize how little you knew before. Rinse, repeat.

This advice is for someone interested in CS as opposed to just programming. Yes, there is a huge difference.

I'm doing the same thing and writing a blog at www.codepo.st. I don't think it really matters what language you start with. After a couple of months you'll find out about different languages and naturally find you way to ones that you like.

Stop reading this thread and start writing some program/app right now.

Don't know where to start?

Simple: Make a Rock Paper Scissors game in C++|Python|PHP|etc.

Really?

Yes. This little game will allow you to learn the basic principles without much frustration.You will use variables, functions, conditional statements, and loops to make it happen. You can then go and use arrays and object oriented programming to learn more. But just focus on making itwork first.

Then, after it sort of works, move into something entirely different.

Like what?

How about a little web app to track your finances?

That's so boring, you might say, but it will teach you many things.

Like:

- Finishing a project is 10000 times harder than starting one. - Many languages in one sitting (HTML/CSS/PHP/SQL/JS/etc.). - How to organize files around. - The importance of comments and readmes. - How to play around with linux to get your stuff to work. - How to work with apache (on XAMPP). - How to work with versioning (GIT, etc).

One last thing:

Don't stop because you are stuck! Push through! Most of the software I build is done so when frustration is navigating around my brain, trying to wreak havoc in the sea of my thoughts.

Note: I know this is rather off-topic, but I'm a long time lurker who saw the opportunity to assist a young mind learn.

had a look at the code (specifically version 1.0). a couple of comments.

first it's not bad! much better code than when i was your age.

second, you have a huge assumption, i think, at line 73 where your code has "repo_age = int(time.time()) - first_commit_time". this assumes that the repository has seen edits recently, but think about a repository that has been dormant for a few months. the score of any bugfix will go down but there's no reason for it to: did bugs get fixed - and less "hot" - when the repo was dormant? no. what you need to do is to find the total timespan of the repository, looking at the min and max times of the commits, then base your scores on that.

If you want to learn anything on a technical level, learn about big-O bounds on runtimes. This will give you an understanding of why some things can't realistically be done by machines. You don't need to hack things together, but you should be able to talk coherently with your tech founders about issues.

If you built an automated scraper that would pick up "stealth" sites (i.e. LaunchRock pages) from various tech publications, Twitter, Facebook when the founders send out links to their friends and family.

Your script checks everyday if those sites are still stealth. The day those sites go unstealth, you put them into a browsable pile.

What you get is a fun site where, on any given day, you can browse through the newest of the new products unveiling on the web without having to rely on tech publications to break them.

.

This was an exercise of a theory I'm working on that helps you generate good ideas. I've been thinking of writing a blog post about this. For now, here are the core ingredients used to make this idea good.

.

The emotive elements used:

- The joy when browsing through Show HN posts.

- Getting rid of the pain of having to keep current with tech blogs.

- Eliminates frustration knowing that tech blogs report only on a small number of products.

- Illicit joy of discovering sites before they are meant to go fully public.

- Meritocratic feel of evaluating each site directly.

- No need to divulge personal email.

.

Key UI elements you can use to magnify the joy:

- Very simple and straightforward keybind that lets you flick through recent "launched" site screenshot. (Using some of the wonderful website screenshot apps here.)

- Ability to take a look at a detailed chart of all the sites under monitoring / # of days in "stealth" / some metric of hype, popularity. Allow sorting by each of those modes.

.

Launch Plan:

- Just release the daily viewer and a simple chart of all the monitored sites. Post on HN in a week.

- Become a new "habit" time waster site for startup founders to browse through everyday.

* Thinking, Fast and Slow: http://amzn.to/sXQGSR - probably makes my list because I just finished it, and as he says "what you see is all there is" - we're biased towards things that come to mind easily. Actually, it is a pretty good book even looking through all the others I've read.

* Built to sell: http://amzn.to/ukmyNP - how to create a business that is something that you can sell because it can exist without you. Not quite so relevant to startups working on a product, but some good concepts nonetheless. A good summary is probably just as good as reading the book, as the core concepts are fairly simple.

* Empires of the Word: A Language History of the World: http://amzn.to/tVvltK the history of the world as seen through languages.

* The Long Divergence: How Islamic Law Held Back the Middle East: http://amzn.to/spQCF7 - a look at how the legal systems of 'the west' and the middle east differed and the results those systems led to.

And of course, if you haven't read this one, I think it's a great read:

Start Small, Stay Small: http://amzn.to/v2DHyx - a great guide full of practical advice on "startups for the rest of us".

What I haven't read:

Lean Startups by Eric Ries. Does it contain much practical advice? I get the impression it's a bit on the 'strategic' side without giving you concrete ideas about how to go about doing things.

The Steve Jobs biography. It looks to be so pervasive and widespread that I'm wondering if I can absorb most of the good parts from other people who have read it. I may get it anyway; we'll see.

FWIW, all links contain a referral code to help fuel my reading habit.

Because of that book, within 3 months I went from running completely out of breath after 2 minutes of running, to finishing a half-marathon in 2 hours. And during the prior 3 months, I had lost 15 kilos by following the "slow-carb diet" described in the book.

Reading it seemed to flip a switch in my brain: before, I would think of my body as something I had little control over, while after, I saw it as not only something I had full control over, but as something I could hack. I've also followed up on quite a few of the product recommendations in the book (e.g. Inov-8 trainers, Aqua Sphere goggles, etc), and have yet to be disappointed.

That said, the book does come with a heavy dose of Tim's pointless boasting, half-assed chapters (e.g. the polyphasic sleep or the baseball batting ones), and far more conjecture than a book of that sort should have.

"An Austrian Perspective on the History of Economic Thought" by Murray Rothbard

This was great because of the history lesson packed into a book that's mostly about economics. I didn't realize how libertarian the economic thought of the east was until I read this book. I also appreciated the focus on economics before Adam Smith since I knew only about Aristotle and St. Thomas Aquinas's contributions prior to reading the book. Rothbard's take-down of Marx was both thorough and satisfying.

"City of God" by Augustine of Hippo

The history lesson here was helpful as was the perspective on how the church should view the state though I should have invested more money in a better version for Kindle. The version I had was filled with grammatical mistakes due to the poor translation to the Kindle format.

It's not tech-related, but my favorite book this year was Nothing to Envy: Ordinary Lives in North Korea. The book is a collection of stories from North Korean defectors, combined with some history and background info. It's a quick but satisfying read.

Prime Obsession : http://amzn.com/0309085497 - a great introduction to the Riemann hypothesis with chapters alternating between the history and impact of the claim, and a dive into the mathematics behind the claim. I have a mediocre background in math (i.e. up through Calculus III in college) but I had no trouble following the chapters explaining the maths behind the hypothesis.

The Undiscovered Self : http://amzn.com/0451217322 - A distillation of much of Carl Jung's lifetime of research in psychology into a short book. The blurb on the book jacket sums it up best: 'In his classic, provocative work, Dr. Carl Jung-one of psychiatry's greatest minds-argues that the future depends on our ability to resist society's mass movements. Only by understanding our unconscious inner nature-"the undiscovered self"-can we gain the self-knowledge that is antithetical to ideological fanaticism.'

Pioneering Swiss art historian Jacob Burckhardt saw the Italian Renaissance as no less than the beginning of the modern world. In this hugely influential work he argues that the Renaissance's creativity, competitiveness, dynasties, great city-states and even its vicious rulers sowed the seeds of a new era. Great book for entrepreneurs, scientists, thinkers, inventors, coders, radicals, and visionaries.

I'm going to be on the receiving end of a great deal of vitriol for saying The Bible and the Koran, but sitting down and reading those two booksâ€"for the first time in my 21-year existenceâ€"was a really interesting experience.

I'm not going to turn this into a personal essay. I realizedâ€"after reading both books with a critical eyeâ€"that there are a lot of trumped-up claims made about each books' contents that ultimately fail to bear themselves out. But there's a great deal to learn from each, and I say this as a nontheist.

Someone once said that 100s of thousands of books have been written to try to express the inexpressible, but only 1 has succeeded... The Book of Mirdad.

> Logic is immaturity weaving its nets of gossamer wherewith it aims to catch the behemoth of knowledge. Logic is a crutch for the cripple; but a burden for the swift of foot; and a greater burden for the winged.

Most people will read two pages of this book and hand it back. But that's their failure, not the books'.

If you read the above quote, and don't get its true meaning, don't get this book, it will read as pure nonsense.

The true meaning is that we (the cripple, all of us) use logic (a tool, the crutch) to help us (which is good), but at some point in time (after you've mastered logic) you reach an understand that there is no right or wrong, no point in progress or success, that the universe does not care about any of this, and that logic now holds you back (from enlightenment).

Using logic, you can be a scholar, even a philosopher, but you'll never reach enlightenment.

This will resonate well with people who enjoy working with their hands. It also has some pretty entertaining anecdotes from the author's personal life, but it's not overly autobiographical. I personally found this one interesting because I've had some similar experiences in life-working on (and driving) an old Volkswagen as a first car, working in the trades, going to college, getting a desk job, and now, thinking perhaps that a desk job isn't for me, as he realized.

On the fiction side, I absolutely loved Shogun by Clavell. I didn't know what to expect, and I found an epic that was captivating in many ways. I also started Neil Gaiman's Sandman series. I realize I'm about 10 years behind everyone else, and I've found it most deserving of all of the hubbub.

With respect to nonfiction, I enjoyed Schroeder's recent biography of Warren Buffett, entitled the Snowball. It was much less of a hagiography than much of what you read on him. He's a fascinating, complex man.

"Bridge of Birds" by Barry Hughart was great. It's a hilarious "detective" novel set in a fictional ancient China. One of the two main characters is an 80 year old sage with a drinking problem and the ability to con almost anybody. The pace never slows and it always has you wondering what'll happen next.

Technically, I'd say "Land of Lisp" has been the most fun and the most rewarding.

"The Dispossessed" by Ursula K. Le Guin. It really challenged many of my beliefs about the underpinnings of society. Quite relevant in the year of Occupy Wall Street as well. Feminist Science Fiction for the win.

A scary tale about the collapse of the various markets across the globe. I constantly had to keep checking to see if the book was from the fiction section. The stories are so far out there it seemed unreal.

I've read a lot of books this year, some have already been mentioned (eg. Gawande, Gombrich). I've been devouring the Game of Thrones books since summer, and as no one has mentioned it yet, I'll point it out.

* The Idea of America: Reflections on the Birth of the United States by Gordon Wood â€" an outstanding collection of essays on the creation of America. They range in chronology from the 1960s until the present time and explore themes like Roman (founders all big devotees and disciples of Cato, Cicero, etc.â€¦ able to recite lines and relished in theater enactments) influence on the founders, the "radicalism" of Paine and Jefferson, the American brew of Enlightenment, monarchy v. democracy (democracy simply had no historical precedent, except for the brief, crude and flawed Athenian model thousands of years earlier), democracy v. republic, etc.â€¦

* Republic, Lost: How Money Corrupts Congress--and a Plan to Stop It by Lawrence Lessig

* Evolution for Everyone: How Darwin's Theory Can Change the Way We Think About Our Lives by David Wilson Sloan â€" â€¦jargon is toned down for a universal audience, and appeal is made that evolution should be broadly applied, and not just confined to the biology domain. 36 chapters, after a gentle introduction, tilt from specific path carving experiments to general queries on religion, morals, human nature.

* Debt: The First 5,000 Years by David Graeber â€" Anthropologist shreds sacred classical "economics" cows on markets, debt, capitalism, etc.â€¦ â€¦hard not to see things after taking in this fantastic research.

* Christian Anarchism: A Political Commentary on the Gospel by Alexandre Christoyannopoulos â€"Â Christian anarchism has been around for at least as long as â€śsecularâ€ť anarchism. The existing literature cites Leo Tolstoy as its most famous (sometimes even as the only) proponent, but there are many others, such as Jacques Ellul, Vernard Eller, Dave Andrews or the people associated with the Catholic Worker movement. Both individually and collectively, these Christian anarchists offer a compelling critique of the state, the church and the economy based on numerous passages from the New Testament. Yet despite the relevance and growth of this literature, no generic study bringing together these different thinkers or reflecting on their contribution has been published to date, because such work involves meticulous searching, compiling and structuring of countless different texts and sources, not all of which are easily accessed. This book, however, provides precisely such a study, and thereby presents Christian anarchism to both the wider public and the wider academic community.

* To Know as We Are Known: Education as a Spiritual Journey by Parker Palmer â€"Â â€¦an eloquent inquiry into "obedience of truth", what it means to educate and to be educated, that to love is "to know" and "to know" is to love. That it is about asking questions and inciting an inner fire, not about authoritarian objectivism or subjective "everyone has their own truth" relativism.

Anathem - Neal Stephenson. Recommended here last year, it blew my mind in a similar way to Name of the Rose but with a sci-fi theme.

Dr Zhivago - Boris Pasternak. If you have not read any of the Russians, give this a go. Initially it is not easy, like all Russian literature, but the wonderfully poetic images and lyricism keep drawing you back. Easily my favourite for the year.

The power of Less: http://amzn.to/t4umWo . It discuss how you can simplify your life. It give many practical advices, and is good for all kinds of people. The message in the book is " be aware and simplify".

Brilliant, Crazy, Cocky. By Sarah Lacy, former writer fo techcrunch. http://amzn.to/vMJwhR. It show how the entrepreneurship and startups are going around the world. As a brazilian reader, I find the picture of brazil very accurate, so the rest of the world must be accurate too. It's a good resource for anyone wanting to understand and know the startup community in countries like India, China, Brazil, Indonesia and others.

If you want to write, by brenda Ueland ,http://amzn.to/w5gQyz: It's a nice book about the craftsmanship of writing. It's a bit 'philosophic' book, but also give a little practical advice. It's and old book, don't be amazed when it refer to the typewriter. And it's very cheap, only 3,99.

And to finish, time warrior, by steve chandler. http://amzn.to/vNBawK If you want a book to beat procrastination, and other modern plagues, this is the book. very practical advice, the book has more then 100 tips. Every should read it.

Thats my favorite books of this year, apart of the ones everyone has talked about, like Steve Jobs bio, Lean Startup, and others startup world books.

It took me 2010 as well as 2011, but I really enjoyed Godel, Escher Bach now I've finally got through it. It's hard going, but I can't think of a book that chnaged what I think about the world as much as that book has.

Best book every year since I read it every year: The Tree of Knowledge. Given how grounded I am in computers, it's important to know what it is to be human. The book starts with simple micro biology and ends by explaining the biological foundation of love. it's the only book I've read that literally changed the way I see the works (and if you read the book you'll know that I mean "literally" in the most literal sense).

It's a difficult book, but some excellent reading guides exist do I highly recommend giving it a read.

Though it's certainly aimed at competitive gaming, I also use it at times as an inspiration for my business. It helps whenever I need to take a second look and play the devil's advocate about my own decisions. Reading it also earned me an extremely effective weapon against procrastination.

"Left in the dark" - a theory about how our mind works. It is either crackpot or one of the most amazing discoveries of the last few decades. Hard to tell which, but it is a very interesting read regardless.

Quite possibly the best book I ever read in my life came out in 2011: The Beginning of Infinity by quantum physicist David Deutsch. http://amzn.to/mSTNCn

It talks about the kinds of ideas that lead to progress in human societies and those that lead to stagnation. I believe Deutsch is, in this book, the first philosopher to actually explain why science works as well as it does. I wish I could do justice to this book in a short review, but instead I can only urge everyone reading this to give it a shot. Read the first chapter, and you'll know you have to read the rest.

Poor Economics - Changed my views on some areas of how to combat poverty and poor education. As well as relating a huge amount a detail regarding the unexpected ways people with different backgrounds behave.

The Exegesis of Philip K. Dick -- Fascinating to have some insight into Dick's thinking and attempts to understand his experiences. The book isn't really something to just sit down and read cover to cover, but more to explore and move around in, but if you love Philip K. Dick it's awesome.

I just finished reading "The Origin of Political Order", which was recommended by Venkatesh Rao. It's refreshing to read an overview of world history that doesn't focus on kings and kingdoms, but rather on the underlying causes. This book covers some dense material, but remains readable at all times. Highly recommended.

I listened to this twice, and applied everything he said to do in my life. I went from a lonely programmer to an extrovert in 18 months. He put Extroversion into words a programmer can understand, as lists of instructions. Now i have so many friends I have to prioritize time with them.

Best read for me is actually a non-tech book; the Dutch "Hoe hoort het eigenlijk" (roughly translated as: "how it should be done") which is considered "the Dutch Etiquette Bible". There is not enough courtesy and etiquette in this world.

The Penguin and the Leviathan. It is an interesting mix of science and anecdotal evidence which hints that most people, most of the time, would actually benefit more from cooperative behavior than they would from competitive behavior.

It's a book on the history of math, focused around the story of math's struggle to deal with infinity. There's really nothing like it. (okay, technically I still haven't finished it, but it's still 2011)

I thought Designers Don't Read was great (don't let the name fool you). It's basically an art director's take on advertising and design with bits of history and insights thrown in: http://www.amazon.com/gp/product/1581156650

Rework. Also, "The Long Run" by Matt Long. Mr. Long wrote a book about his experience as a NYC firefighter who, a few days after qualifying for the Boston marathon, got run over by a bus while riding his bike and literally got split in half up to his chest. Almost two years later, he ran the New York City marathon and went on to do the ironman. Insanely great story and the book is a good read. His story was inspiring to never give up.

It was recommended by several friends, and I finally got around to reading it. Helped, along with Zen and the Art of Motorcycle Maintenance to work through my personal thought process. Highly recommended.

Down and Out in Disneyland - Cory Doctorow (This was gifted by a friend and really inspired me to make some significant changes in my life. That includes the decision to learn to code and escape the user end of the spectrum.)

Procrastination- Jane B. Burka , Lenora M. Yuen (This book has fundamentally altered my introspective conclusions. That is to say, I am now more aware of times when I am procrastinating and the impact it has on my life.)

This year was a great year for reading and I hope to read even more next year.

Many books mentioned here are good, this is the only I haven't seen referenced. But this one book really helped me deal with resistance and get stuff done. Seth Godin is a big fan and references it a lot in his material.

Steven Pressfield also wrote 'The Legend of Bagger Vance' and Gates of Fire (Spartan 300 kind of book but way deeper).

Design for Hackers by David Kadavy. Besides being informative it was really really interesting to read. Really opened my eyes to a lot of the things designers do deliberately and not just because "its pretty".

"Go the F--k to Sleep", by Adam Mansbach. It's a great book that's helped me much in my personal life. I used to have trouble falling asleep at night, often finding myself worrying about issues that had come up during the day, and being unable to put work away when I needed to sleep. Since reading it, I've found that I can put away these fears and problems far better than I could before. I highly recommend it to anyone who has trouble sleeping from time to time.

"Incognito - The Secret Lives of the Brain" (http://amzn.com/0307377334) blew me away. Very interesting read on the current understanding of how the brain/consciousness work and the implications of these models on free will, etc.

The Emperor of All Maladies - spectacular journey into the history of the disease. Filled with great human stories of discovery, and also taught me a ton about the currently understood biology of cancer.

Musashi by Eiji Yoshikawa. Highly recommended for anyone who has discipline problems, it is really inspiring, one of the top 3 books I've read. It tells the history of the real samurai named Miyamoto Musashi.

It's too easy to get caught up in the fad where you see blog posts bragging about launching in 3 hours with a crappy website and bagging their first customer.

.

(Note: This is all based on my meandering experience. Take it with a grain of salt.)

For me, a MVP tackles a single sub-problem of your targeted userbase and execute the heck out of it. This should be a gem of a small solution you create that is beautiful, usable, and magnificent.

Your goal is to get those initial users to feel that heady emotion (Wonderful word: "frisson"), that sends chills down their backs when they realize what you have created.

.

Not taking advantage of graphic design is stupid. Remember, when users see that MVP, they don't consciously think, "ok, this site does X, but it has a graphic design quality of Y, but I don't care". They take in the MVP as a whole and they put it through their binary evaluator.

You need to take advantage of everything at your disposal to make sure that evaluator lands on the right side. To do anything less would be doing yourself a disservice.

You don't want to be sitting a few days after sending out the MVP and wondering if people aren't converting because it looks crappy or because its useless.

(A big caveat is if you don't have a designer on your team. At this stage, it is time consuming (and expensive) to hire freelancer designers to render the vision you have in your head. I would try to make do. I come from the school of thought that having a designer cofounder is essential, and better yet, you have a designeer on your founding team.)

.

Remember, all I am talking about is just one small aspect of the bigger problem you are trying to solve. The bet here is that with your identified subproblem, the costs for producing it will be relatively low (at least compared to the overarching problem you are solving).

.

It is easier for people to see a tiny, tiny bit of something absolutely wonderful and imagine a lot more of it than it is to see something crappy and imagine something beautiful.

.

What ends up happening is:

1. Potential users try out the MVP and appreciate its straight up utility.

2. Potential users see the quality and craftsmanship of the tool (even though its tiny) and you start gaining a fanbase. These users expect more wonder from you.

3. It becomes very natural for you to grow out your userbase along with your feature set.

4. You tackle more subproblems with the same amount of polish and voracity and in the end you get a wonderful product with a huge fanbase.

.

jiggity's personal mvp pathway to new products

Research -> Identification of one pressing subproblem -> Build the heck out of a solution to that subproblem -> Polish, make it beautiful, put in emotive triggers -> MVP release -> Userbase reacts with astonishment -> Identify pressing subproblem #2 -> Built solution for that subproblem -> Polish -> Release -> Use fanbase from earlier iteration to grow much faster -> Repeat

If the purpose of the application is met, but the app is otherwise ugly, hard to use or what have you, then you have an MVP.

The point of an MVP, generally, is to determine whether or not there's a market for your application, and whether it actually fills a need.

If you can put out an ugly, half-working application that saves me real, tangible money, then I'm probably going to use it. If there's better-looking or more highly regarded software in the same space, you're out of luck, and shouldn't be launching an MVP... the market's been proven by the competitor. But if it's a new space, in an unproven market, that solves a real problem, then yes, I will accept an app that hasn't "had time to polish the features", so long as the one core feature that I'm using it for works.

Unless you know people up here then your best bet is look for temporary housing for a few weeks while you drive around and look for places via craigslist/similar. Areas are notorious for having very high housing prices for crappy places that just have a fresh coat of paint on them, so looking on internet only without site visits is not a great option. I spent one month looking for a place in Mountain View and found that renting a condo from an owner turned out to be better all around than trying to find a suitable apartment complex. Another problem is that decent housing is super competitive here, a reasonable rental purchase will get replies almost immediately, so owners will prefer to deal with local people than those farther away to close the deal.

I think he has stated before, or it has been implied by others, that releasing the source for hacker news might do more harm than good. There is a significant problem with voting rings now from the sounds of it. Hacker News has become a force that can greatly affect business and startups. If the voting ring people had the source, they might be able to find an exploit more easily that allows them to game the system. Clearly that would hurt Hacker News as a whole.

Basically, there are more black hats than white hats who would take a look at the source. YC is too powerful now.

Imagine that you have a non-session-persisting load balancer in front ofa cluster of web servers (n >= 3). Since this load balancer doesn'tdirect requests in any persistent fashion, a user making subsequentrequests may be directed to any of the servers available in the clusterin a non-deterministic manner. In your application, you need to handleimage uploads from users, and as soon as the upload is finished, youneed to show the user their uploaded image. This creates a problem foryou because after an upload, the load balancer may direct the user to aweb server which does not have the users recently uploaded imageresulting in a 404 Not Found for the image request and a poor userexperience.

In the current system, an rsync process runs every 5 minutes and copiesuploaded images around to each server so that every server has everyfile, eventually. This isn't a very optimal solution because users maynot see their uploaded images for up to 5 minutes depending on whichserver they are connecting to for any given request and it forces everyserver to have a copy of every image uploaded, which may not be the mostscalable solution.

Assuming you could not modify the load balancer, how would you redesignor fix this system so that files are uploaded in a way that it doesn'tmatter which server in a cluster a user connects to in order to be ableto satisfy a request for the file? There are many ways to solve thisproblem. Please describe one or more ways and discuss the pros and consof your solution(s). If your solution is very simple (not a bad thing),consider offering a couple alternate solutions so we have a strongunderstanding of how you evaluate and approach problems.

-

My Response:

Basically that this was poor architecture and didn't make sense. They shouldn't be using their web servers as a file store. They didn't like that.

I was recently asked given a variable amount of parameters passed into a JavaScript function how would you sum all of the parameters. My answer was I would not write JavaScript code like that, and would fire anyone on my team that did. Needless to say I did not get the job, nor did I want it. I have been critical of this type of interviewing for a long time. Trick questions and magic code really provide little insight to the value of a candidate. Further most interviewers do not have the clinical background to even interpret the results as many of these questions are based off of psychological tests. It's a cargo cult mentality and reflects poorly on an organization.

I can't speak for BlueHost, but bad neighbors are hard to deal with in pure 'shared hosting' environments, and are regrettably unpredictable, and hence harder to mitigate against.

I've had similar problems in the past with Dreamhost and its ilk.

For a little more money, you can switch out to Linode which is at least VM-based instead of fully-shared platform, but the tradeoff is that it is more expensive, and you also have to administer your own services. It's also possible that you lose some of the burstability of a shared hosting platform as the caps are hard caps.

BlueHost doesn't rate all that badly on the shared hosting chart (I am tracking this data - they are 6 out of 19 among some of largest providers). That sort of behavior sounds like crap, but it happens to most of them because of the nature of shared hosting. I am not sure that half a day to get a SQL load under control is normal though. I've had hosts just suspend my account right away when I go over or they kill the offending script.

The fact is, in gaming customers will take a lot of abuse, it is evident in the email exchange where the customer Dave I think his name was does not cancel his order. So the risk of driving away customers that want this product is probably small, given that the recipient of the abuse still wanted the merchandise. Where in most other industries a customer would say you know what cancel my order. Sony's antics are further proof that some gamers have a high threshold for abuse. So given that there is a high upside for publicity with a low downside of canceled orders over the fiasco. Given that it is a third party, they can dispose of them and claim that they are innocent. I am not saying this is what happened but it cannot be ruled out.

I think you will find most people don't walk away from this with a full understanding of who is to blame. Instead, many may create a sub-conscious linkage with the Avenger and a bad customer service story. It's easy to create perceptions and difficult to remake them.

Maybe it does work well for N-Control this time....but a strategy? I'd like to hear what marketing professionals would say, but it sounds much too risky for me.