

Advice for Graduate Students: Suggestions for a Basic-Research Career - bd
http://www.psychology.buffalo.edu/essay.shtml

======
jballanc
Unfortunately, at this point in time, I feel very strongly that these
suggestions will lead you to do good science and end up without an Academic
Research position...at least, not initially. Personally, I think we need a
revival of Franklin/Jefferson/Priestley/Watt type science, where the science
is pursued for fun and interest, instead of for profit. The current petty
competition for publications and grant money is the worst thing to happen to
science.

~~~
sketerpot
Maybe we should return university science to the Sputnik Golden Age style of
funding: once you've shown that you know what you're talking about, you just
get loads of funding and just publish papers to keep it coming. According to
folks who were doing science back then, it was glorious; they could get work
done so much faster!

And just think of the international consequences. If the US became the land of
easy funding, it would definitely keep a lot of foreign talent around. This
sort of thing is a competitive advantage, and probably pretty cheap.

~~~
tybris
Seems like the EU is making an effort <http://www.few.vu.nl/~ast/>

------
dschobel
_4\. If you do basic research, keep your eyes open for applications of your
findings._

I'm always reminded of one of my grad school profs who said that the goal of
any research should either be commercial or something which will end up in a
text-book.

Everything in between is just filler.

~~~
yters
That is something that really turned me off to academia as I worked through my
masters.

~~~
alexitosrv
been there, done that.

------
ktharavaad
1\. Establish an independent niche in the market as early in your startup as
possible. Avoid the web2.0 startup trap of following hype implementing ideas
that are already popular and profitable. Of course social networks are
helpful, but just-another-social-network can't form the basis of your startup

2\. Be problem-oriented, not technology-oriented. Use a variety of technology
-- whichever are necessary to solve the problems in the market. As shown by
twitter, back in the days of ruby&rails popularity and DIY-everything, it
would take twitter considerable resources to assemble a new queueing queuing
system which sucks, when existing better alternatives existed. lest the
founder be seduced into implementing another overdone component/api in a brand
new web2.0/meta-meta-programming language. It is also painful to hear one
startup after another say that "we are based on ruby and rails", as if this
makes them cooler. While this may interest potential non-technical investors
who judge the value of startups by the amount of the lattest technology
jargons founders put into their keynote/powerpoints, its simply a waste of
resources for the company in the long run. Remember, technology comes and
goes, but the underlying need of the market should be the focus of the
startup. It is depressing to go to conferences where the same old market
problems are tackled; more “cutting edge” techniques, presented by people
enamored of the techniques rather than the market problems. If technology is
so costly, in terms of equipment, learning time, and other resources, how does
one avoid the trap of becoming technique oriented? The answer: use what is
already out there, leverage open source and solve real problems in the market.

3\. Think beyond the next hype, or even the next round of investing. Take the
long view; look at the big picture. In other words, bite off a piece of
question that may take a month, or even a year to answer. There is a major
difference between the scientist that wonders how to break the question into
appropriate sized grant proposals, and one who wonders how to expand the
question into a grant proposal. Furthermore, commit yourself to your question;
given the time and energy it takes to answer an appropriate sized research
question, pursuing a series of unrelated research questions in parallel rather
than in series is often a sign of dilettantism.

4\. If you do developed a new technology in your startup, keep your eyes open
for other applications of your findings. On the other hand, if you heavily
leverage an existing technology, keep your eyes on underlying
technology/framework. Often, the distinction between technology and
application is arbitrary and fluid.

5\. When conducting market resource, don’t accept data or results at their
face value. Keep plugging away at the problem until the answers or results
make sense or satisfy you in terms of an overall schema. Most importantly,
don’t accept other company's solutions (37 signals?); every startup is
different.

6\. Expect the unexpected. Many great ideas are discarded because a startup
initially “didn’t work”. However, good execution should provide positive
results regardless of the idea involved. Often a "good idea" and a "bad idea"
is only differentiated by the execution.

7\. Don’t expect quick success in a startup; expect more hardship, sacrifices,
sweat, blood and tears. Paul Graham used to tell us that a good startup often
require years of work to build up. Perhaps non-entrepreneurs find this aspect
of startups strangely frustrating. However, the lack of dedication and
handwork differentiate the success and failures

8\. Never stop asking for user feedback. User feedback are the stock-in-trade
of startups. The corollary of this suggestion is “never make assumptions.” Of
course, assumptions are a necessary part of application design, but on an
everyday practical level, and in terms of application workflow, assumptions
can be disastrous. Many times I’ve located workflow bugs and inefficiencies in
a startup's application workflow, because unlike them, I did not assume that a
user could not “go there” or “do that”.

9\. Choose a problem that excites you. It should excite you so much that you
can’t sleep. It should excite you so much that when someone asks you the time,
you blurt out your 30 second elevator pitch.

10\. Strive for elegance and cleanliness in yoru code. The elegance of a
codebase is in the quality of the thinking and the cleverness of the approach
to solving the market's problem, not in the complexity of the design or the
sophistication of the technology. Often, the most elegant code are simple,
short attacks at the heart of the problem. Study famous open source code in
your application domain and appreciate the logic and thought that went into
it. All too often startups nowadays ignore existing codebase because it isn’t
available on github, or dismiss it for using old-fashioned techniques. There
is much wisdom and cleverness in some of those old projects. Reading them,
learning from them, and citing them, is what real programmers do.

~~~
bigbang
Though seems obvious, very good advice esp #1-2

