这个网站，有姐妹认识么？# Fashion - 美丽时尚
w*z
1 楼
二爷威武阿，走在大家前头阿。下一步该搞open source？
http://www.javaworld.com/javaworld/jw-03-2013/130314-on-becomin
Developer tip No. 1: Blog
Set up a blog, and post more than once a month. Do real research and make
sure you don't sound stupid. Seriously, learn to write. Do the stuff your
grade-school English teacher taught you: Create an outline, draw a narrative
, check the grammar and spelling. Then, with great sadness, simplify it and
shorten it to the point enough where someone scanning it will have an idea
of what it's about. The Internet does not tolerate nuance (nor does my
editor).
Developer tip No. 2: Go open source
Don't believe the lies about open source. The younger among you may not
remember the days where a developer could actually be unemployed, but even
during the darkest stretches of the dot-bomb recession, all of the
developers of the open source project I started were quickly back at work.
Just make sure the open source code you produce reflects the kind of job you
want. I wanted to solve hard problems with the simplest solutions possible,
but I've interviewed developers who, as was clear from their open source
code, wanted to complicate simple problems. Believe it or not, there's a
market for that, but make sure your code reflects the market you're in.
Developer tip No. 3: Not six months, not 10 years
Don't switch jobs every six months. Seriously, the end of 100 percent
developer employment will come again. When that time arrives, nothing will
haunt you more than job-hopping. On the other hand, don't stay at the same
place doing the same thing for 10 years. You'll become insulated and
institutionalized. To stay valuable, you have to be familiar with more than
how to code IBM's stack while at IBM in the IBM way. I haven't hired anyone
who was at IBM or a similar organization for more than a year or two. They
usually impress me in the interview but fail the programming test.
Developer tip No. 4: Eye on the new stuff, hands on the practical
Exceptionally young developers have a tendency to work on the shiny. Ruby is
probably my favorite programming language, but it doesn't pay (on average)
as much as Java, and the market is smaller. This may not always be true.
Scala looks like it's coming on strong, but don't kid yourself about the
market size -- it isn't here yet. On the other hand, don't stay still so
long that you are the future equivalent of a COBOL or PowerBuilder developer
either.
Developer tip No. 5: Write your own documentation
I can't tell you how many times I've worked on a project, only to be pulled
into an executive meeting because I wrote a document or presentation they
saw and understood. I always begin with an executive overview -- that is,
the page you really have to read -- while the rest boils down to details in
case you don't believe me. The question is: What does a very busy person
have to know about the topic if it's not the only thing they're working on?
What most managers want to know: Who can drive this to completion and won't
BS me about how it's going? Write that way.
Developer tip No. 6: Brevity is the soul
One thing you learn about management right away is that the people who know
what they're talking about tend to give shorter, more concise answers. When
the responses grow long and complicated, it often means they don't know or
won't commit. You also learn that tone is often inversely proportional to
the importance of the topic. When really bad news hits, someone comes in the
office, shuts the door, and whispers. When something is not inherently
important but bothers someone anyhow, they will try and raise its prominence
with an inflammatory tone.
Don't be that guy. Know what you're talking about, figure out how to
summarize it, and have the details, but don't load every sentence with
minutiae and don't build up the hype -- the sky probably isn't falling (but
maybe someone should take a look at Jenkins because we haven't had a good
build in a while). When all else fails, lead with the money. Make sure your
numbers are well thought out, plug them into charts, and clearly demonstrate
that one point is superior to another in dollars and cents.
Developer tip No. 7: Wow the crowd
Figure out how to give presentations and learn how to speak in public.
Research a topic and make yourself at least an expert, if not the expert.
Presentations to the public are generally better if they are in part
entertaining. It takes a lot of embarrassing mishaps to develop this skill,
but an engineer who can explain the matter in plain English to management
and give an expert talk on a topic will almost always command a higher
salary than one who doesn't.
Developer tip No. 8: Be realistic
Sure you like Erlang, but the market for Erlang isn't big. You should know
more than one language, as well as "new" or newly hyped topics, but avoid
such immature statements as "I won't code unless it's in Erlang" unless you'
ve truly considered the business issues. It can pay to be a narrowly focused
expert, but even that has a cost -- you'll be typecast according to your
specialization, which may leave you high and dry when it's out of fashion.
Sure, NoSQL is a better fit for your little project, but the company won't
invest in it for a small one-off system. The RDBMS will work fine for this
one.
Developer tip No. 9: Solve the hard stuff, know the tools
Put in the time to learn a few tools other people don't commonly know. What
tools do you have that few know/use/understand and make you more effective
than the people next to you?
For example, Aspect4j is not for everyone, but it sure as heck is for me. I
use it for things that are wrong -- very wrong. I've rewritten .class file
operations to make them run in Tomcat instead of WebSphere, though the
original source was missing. I've fixed memory leaks in proprietary software
. I've implemented a poor man's Wily Introscope. At each point, I looked
like some kind of supergenius because I had a tool that few people had
grokked yet -- and bothered to keep going when others decided to wait for
the vendor. I live/breathed eclipse.org/mat so that I could not only fix
leaks but tell you what struts action and parameters caused your OOME. There
are others, but these simple tools for complex problems put a shine on a
developer.
Developer tip No. 10: Practice humility
This is the least common skill among developers. Sometimes it means you get
your hands dirtier than you want. Other times it means you don't let it go
to your head when you pack a room. Geek fame comes and goes, but remember,
it's what you did recently that brings them in. Next week, it could all be
gone. In the words of Tyler Durden, "You are not special." Yes, trolls, I'm
fully aware of the irony.
How do you know you're sought after?
Look left, look right: Is there a row of people doing basically what you're
doing? Then you're not there yet.
Here are some signs that you've arrived: You're sitting in a row of people
and they're all looking at you. People take their picture with you and you'
re not an American traveling in Japan. Your speaking engagements fill the
house, and people tell you about how much they not only enjoyed your talk
but also the last two you gave. The sales and marketing people actually
value your opinion. Does that sound like you? Congratulations, you've made
it.
That said, fame and success are fleeting, and you have to keep it
interesting. Ironically, as you become a more sought-after developer, you
code less and less. It becomes more economically efficient to communicate to
and motivate others, as well as to delegate your "tend to" stuff. That may
or may not be what you signed up for.
There will be times in your future when, once again, not every software
developer who wants a job can get one. Particularly when the atmosphere
becomes Darwinian, effective self-promoters do better than quiet toilers.
http://www.javaworld.com/javaworld/jw-03-2013/130314-on-becomin
Developer tip No. 1: Blog
Set up a blog, and post more than once a month. Do real research and make
sure you don't sound stupid. Seriously, learn to write. Do the stuff your
grade-school English teacher taught you: Create an outline, draw a narrative
, check the grammar and spelling. Then, with great sadness, simplify it and
shorten it to the point enough where someone scanning it will have an idea
of what it's about. The Internet does not tolerate nuance (nor does my
editor).
Developer tip No. 2: Go open source
Don't believe the lies about open source. The younger among you may not
remember the days where a developer could actually be unemployed, but even
during the darkest stretches of the dot-bomb recession, all of the
developers of the open source project I started were quickly back at work.
Just make sure the open source code you produce reflects the kind of job you
want. I wanted to solve hard problems with the simplest solutions possible,
but I've interviewed developers who, as was clear from their open source
code, wanted to complicate simple problems. Believe it or not, there's a
market for that, but make sure your code reflects the market you're in.
Developer tip No. 3: Not six months, not 10 years
Don't switch jobs every six months. Seriously, the end of 100 percent
developer employment will come again. When that time arrives, nothing will
haunt you more than job-hopping. On the other hand, don't stay at the same
place doing the same thing for 10 years. You'll become insulated and
institutionalized. To stay valuable, you have to be familiar with more than
how to code IBM's stack while at IBM in the IBM way. I haven't hired anyone
who was at IBM or a similar organization for more than a year or two. They
usually impress me in the interview but fail the programming test.
Developer tip No. 4: Eye on the new stuff, hands on the practical
Exceptionally young developers have a tendency to work on the shiny. Ruby is
probably my favorite programming language, but it doesn't pay (on average)
as much as Java, and the market is smaller. This may not always be true.
Scala looks like it's coming on strong, but don't kid yourself about the
market size -- it isn't here yet. On the other hand, don't stay still so
long that you are the future equivalent of a COBOL or PowerBuilder developer
either.
Developer tip No. 5: Write your own documentation
I can't tell you how many times I've worked on a project, only to be pulled
into an executive meeting because I wrote a document or presentation they
saw and understood. I always begin with an executive overview -- that is,
the page you really have to read -- while the rest boils down to details in
case you don't believe me. The question is: What does a very busy person
have to know about the topic if it's not the only thing they're working on?
What most managers want to know: Who can drive this to completion and won't
BS me about how it's going? Write that way.
Developer tip No. 6: Brevity is the soul
One thing you learn about management right away is that the people who know
what they're talking about tend to give shorter, more concise answers. When
the responses grow long and complicated, it often means they don't know or
won't commit. You also learn that tone is often inversely proportional to
the importance of the topic. When really bad news hits, someone comes in the
office, shuts the door, and whispers. When something is not inherently
important but bothers someone anyhow, they will try and raise its prominence
with an inflammatory tone.
Don't be that guy. Know what you're talking about, figure out how to
summarize it, and have the details, but don't load every sentence with
minutiae and don't build up the hype -- the sky probably isn't falling (but
maybe someone should take a look at Jenkins because we haven't had a good
build in a while). When all else fails, lead with the money. Make sure your
numbers are well thought out, plug them into charts, and clearly demonstrate
that one point is superior to another in dollars and cents.
Developer tip No. 7: Wow the crowd
Figure out how to give presentations and learn how to speak in public.
Research a topic and make yourself at least an expert, if not the expert.
Presentations to the public are generally better if they are in part
entertaining. It takes a lot of embarrassing mishaps to develop this skill,
but an engineer who can explain the matter in plain English to management
and give an expert talk on a topic will almost always command a higher
salary than one who doesn't.
Developer tip No. 8: Be realistic
Sure you like Erlang, but the market for Erlang isn't big. You should know
more than one language, as well as "new" or newly hyped topics, but avoid
such immature statements as "I won't code unless it's in Erlang" unless you'
ve truly considered the business issues. It can pay to be a narrowly focused
expert, but even that has a cost -- you'll be typecast according to your
specialization, which may leave you high and dry when it's out of fashion.
Sure, NoSQL is a better fit for your little project, but the company won't
invest in it for a small one-off system. The RDBMS will work fine for this
one.
Developer tip No. 9: Solve the hard stuff, know the tools
Put in the time to learn a few tools other people don't commonly know. What
tools do you have that few know/use/understand and make you more effective
than the people next to you?
For example, Aspect4j is not for everyone, but it sure as heck is for me. I
use it for things that are wrong -- very wrong. I've rewritten .class file
operations to make them run in Tomcat instead of WebSphere, though the
original source was missing. I've fixed memory leaks in proprietary software
. I've implemented a poor man's Wily Introscope. At each point, I looked
like some kind of supergenius because I had a tool that few people had
grokked yet -- and bothered to keep going when others decided to wait for
the vendor. I live/breathed eclipse.org/mat so that I could not only fix
leaks but tell you what struts action and parameters caused your OOME. There
are others, but these simple tools for complex problems put a shine on a
developer.
Developer tip No. 10: Practice humility
This is the least common skill among developers. Sometimes it means you get
your hands dirtier than you want. Other times it means you don't let it go
to your head when you pack a room. Geek fame comes and goes, but remember,
it's what you did recently that brings them in. Next week, it could all be
gone. In the words of Tyler Durden, "You are not special." Yes, trolls, I'm
fully aware of the irony.
How do you know you're sought after?
Look left, look right: Is there a row of people doing basically what you're
doing? Then you're not there yet.
Here are some signs that you've arrived: You're sitting in a row of people
and they're all looking at you. People take their picture with you and you'
re not an American traveling in Japan. Your speaking engagements fill the
house, and people tell you about how much they not only enjoyed your talk
but also the last two you gave. The sales and marketing people actually
value your opinion. Does that sound like you? Congratulations, you've made
it.
That said, fame and success are fleeting, and you have to keep it
interesting. Ironically, as you become a more sought-after developer, you
code less and less. It becomes more economically efficient to communicate to
and motivate others, as well as to delegate your "tend to" stuff. That may
or may not be what you signed up for.
There will be times in your future when, once again, not every software
developer who wants a job can get one. Particularly when the atmosphere
becomes Darwinian, effective self-promoters do better than quiet toilers.
