Real geeks die early(norbu09.org)
norbu09.org
Real geeks die early
http://norbu09.org/2010/05/05/every-once-in-a-while.html
41 comments
Apparently so do their shift keys.
And their kerning.
EDIT: Yep, http://norbu09.org/css/screen.css:
EDIT: Yep, http://norbu09.org/css/screen.css:
#content p {
line-height: 140%;
letter-spacing: -0.03em;
}does it bother you that people don't capitalize properly in their personal blogs? i never understood that. i read through it just fine.
i know it's proper, but i guess i'm kind of lazy in that way. in the words of christopher walken: "i never liked capitalization. it felt like more of an imposition."
i know it's proper, but i guess i'm kind of lazy in that way. in the words of christopher walken: "i never liked capitalization. it felt like more of an imposition."
It bothers me; lack of capitalization makes me think a person didn't care enough to read over what they wrote even if it is just looking at the text as they write it.
I just found it to be an unnecessary distraction.
It's not that it bothers me. It just makes it more difficult than necessary for me to read. I make an assumption that by posting something on the internet, the person wants me to read it and wants to share their ideas with me.
Why distract readers from one's ideas by not following simple grammatical convention?
It's not that it bothers me. It just makes it more difficult than necessary for me to read. I make an assumption that by posting something on the internet, the person wants me to read it and wants to share their ideas with me.
Why distract readers from one's ideas by not following simple grammatical convention?
th prblm s nt tht ts mprpr, bt tht yr gvng th rdr lss nfrmtn
It looks like no-vowels slows down my reading to about 50% of original speed, whereas no-caps slows me down only to maybe 90%. This might be because I spend so much time on IRC.
if acronyms and proper names were capitalized, we'd have everything covered? punctuation already signals the end of a sentence.
i could read and comprehend what you said in your example, but it required more mental effort. i don't think reading a blog without caps requires more mental effort, but if it does to most people, then i might have to switch back.
i could read and comprehend what you said in your example, but it required more mental effort. i don't think reading a blog without caps requires more mental effort, but if it does to most people, then i might have to switch back.
Only 1/3 of the periods in e.g. this sentence signal the end of it.
i believe the correct grammatical use of "e.g." uses commas anyway, in which case i would have easily understood the example without caps:
only 1/3 of the periods in, e.g., this sentence, signal the end of it.
only 1/3 of the periods in, e.g., this sentence, signal the end of it.
No, whether you want commas depends on the sentence. Most good writers wouldn't punctuate that sentence as you did. Too halting for such a short sentence.
But this is not the point here, is it? The point is that any abbreviation with periods in it could appear in the middle of a sentence.
But this is not the point here, is it? The point is that any abbreviation with periods in it could appear in the middle of a sentence.
i don't think i'd use it that way either. i did a quick google search to check and the first thing that came up was this: http://ancienthistory.about.com/od/abbreviations/f/ievseg.ht...
i can only think of three exceptions where you'd need capitalization for additional information: acronyms, proper names, and abbreviations.
i've been doing this as a test since may 13, 2009. i've never run into the problem of a misunderstanding before due to lowercase and i usually write this way in all casual written forms of communication (email, sms texting, blogs, comments). i originally picked it up from a designer i admired back in 2008, and the habit kind of stuck after trying it.
i can only think of three exceptions where you'd need capitalization for additional information: acronyms, proper names, and abbreviations.
i've been doing this as a test since may 13, 2009. i've never run into the problem of a misunderstanding before due to lowercase and i usually write this way in all casual written forms of communication (email, sms texting, blogs, comments). i originally picked it up from a designer i admired back in 2008, and the habit kind of stuck after trying it.
But it's not about misunderstanding. We've all been on the Internet long enough to be able to slog through 1337speak and poor spelling and grammar, if we have to, with probably 99% understanding. However, it takes longer. As it is with capitalization--it doesn't prevent overall understanding, but it does slow it down, at least a little.
That said, maybe that's acceptable to you. Maybe you're going for a certain aesthetic.
That said, maybe that's acceptable to you. Maybe you're going for a certain aesthetic.
the point pg made, which i was responding to, was: "it's not about being improper, it's that you're giving the reader less information," so i was addressing that.
the original point was "does it slow you down to read this blog because there are no caps?" i don't know whether a majority of people read lowercase slower--nobody has mentioned it since i started doing it a year ago. i personally have no problems with it; i'm not doing stuff like omitting vowels (an extreme example to make a point, imo). i'm just skipping over the shift key.
it's not about aesthetics in my case. more about laziness in typing, and i don't want to do something just because "that's the way it's always been done."
the original point was "does it slow you down to read this blog because there are no caps?" i don't know whether a majority of people read lowercase slower--nobody has mentioned it since i started doing it a year ago. i personally have no problems with it; i'm not doing stuff like omitting vowels (an extreme example to make a point, imo). i'm just skipping over the shift key.
it's not about aesthetics in my case. more about laziness in typing, and i don't want to do something just because "that's the way it's always been done."
Well, there was a politicised line of thought in 20C modernist typography towards abandoning capitals due to their implied hierarchies. Herbert Bayer’s experimental Architype (http://en.wikipedia.org/wiki/Bayer_Architype) would be one example of a specific typeface designed with this in mind, but there were also many other typographic designs of the time which abandoned capitalisation.
We’re still seeing the filter down of these experiments now, every few years another company rebrands and drops their capital letters to “humanise” their image or some such reasoning.
So… maybe it was a conscious decision by the author along these lines. Or as you say probably just a broken shift key.
We’re still seeing the filter down of these experiments now, every few years another company rebrands and drops their capital letters to “humanise” their image or some such reasoning.
So… maybe it was a conscious decision by the author along these lines. Or as you say probably just a broken shift key.
my shift key is fine (programming in erlang actually forces me to use it) but growing up in a non english country - and being forced to a lot more capitalization than english has - made me decide to refuse the capitalization thing entirely. it was a mix of movement and point against overly stressing the beginning of sentences and i somehow stuck with it. did not think that is was that much of a problem though :-)
It's not a huge problem. I enjoyed your post and can relate. Thanks for sharing it.
I am making a transition from being a developer to a manager these days. I consider myself a passionate developer, and hence I never thought twice about spending time beyond 9-5 and getting a job done (as it made me happy). Now that I am a manager, I am working with multiple resources, some of which like to work for work's sake, some are good resources that will only work 9-5, and some losers that won't get a good job done at all.
Could someone explain how they manage people who won't
a)estimate right when given the chance,
b) understand the criticality of the deadlines,
c) put in a fair 40 hr/week if the deadline is still a month away (i.e. start missing internal milestones from day one),
d) not escalate/be concerned unless you probe them etc?
Could someone explain how they manage people who won't
a)estimate right when given the chance,
b) understand the criticality of the deadlines,
c) put in a fair 40 hr/week if the deadline is still a month away (i.e. start missing internal milestones from day one),
d) not escalate/be concerned unless you probe them etc?
a) Nobody can be "given" the chance to estimate accurately. Either you already know the code and know exactly what you're going to do, or you're just guessing, hoping that the task will prove similar to something you've done in the past.
b) People are used to being lied to about criticality, and "understanding" the criticality of deadlines is usually code for working extra hard to compensate for planning mistakes, unplanned work, or other people's mistakes. The willingness of developers to work unpaid overtime to meet deadlines should be marveled at and appreciated. It's not like we're respected as professional-class people (doctors, lawyers, etc.) We're just "resources" who are usually suckers enough to work unpaid overtime when needed. Don't complain when we actually do the sensible thing and leave at 6pm.
c) Putting in a fair work week and hitting internal milestones "from day one" are not the same thing.
d) Good managers stay in touch. It's part of the job. Just accept it.
b) People are used to being lied to about criticality, and "understanding" the criticality of deadlines is usually code for working extra hard to compensate for planning mistakes, unplanned work, or other people's mistakes. The willingness of developers to work unpaid overtime to meet deadlines should be marveled at and appreciated. It's not like we're respected as professional-class people (doctors, lawyers, etc.) We're just "resources" who are usually suckers enough to work unpaid overtime when needed. Don't complain when we actually do the sensible thing and leave at 6pm.
c) Putting in a fair work week and hitting internal milestones "from day one" are not the same thing.
d) Good managers stay in touch. It's part of the job. Just accept it.
Agreed. You may want to see another comment I've made where I would be ok if they can explain the delay with a valid reason for it - personal reasons/infrastructure issues/unexpected complexity.
The basic point you are making is that if there are unplanned/under-planned developments, we need to account for them in a way that's humane, rather than forcing the developer to hold on to an arbitrarily identified date. I am all for it, but in my case, I am not getting any good reason for the delay, just a note that things are delayed.
The basic point you are making is that if there are unplanned/under-planned developments, we need to account for them in a way that's humane, rather than forcing the developer to hold on to an arbitrarily identified date. I am all for it, but in my case, I am not getting any good reason for the delay, just a note that things are delayed.
> I am working with multiple resources,
First step: stop calling people "resources"
First step: stop calling people "resources"
Second step: stop referring to people as "which". "which" is for things, "who" is for people.
Replying to param, but don't want to spam another comment:
> "b) understand the criticality of the deadlines,"
Why is the deadline critical? For whom? What is the programmer's stake in this deadline, and do your people feel like they have been treated fairly?
To answer the first part, ask yourself seriously: what happens if we don't hit this deadline? Does it truly impact the company and/or team, or does it impact you?
I've seen many a time when deadlines are touted as hyper-critical, but have minimal actual business impact. They were hyper-critical because it was critical for the manager to get it done on-time, otherwise he/she looks bad. This is not something I would normally presume about a manager, but you've already demonstrated some misguided overly corporate buzzword-notions in your post.
I personally am much more likely to trust my manager's prioritization of tasks (and thus, deadlines) when I feel that he is looking out for the team (or hell, the company) rather than himself.
Replying to param, but don't want to spam another comment:
> "b) understand the criticality of the deadlines,"
Why is the deadline critical? For whom? What is the programmer's stake in this deadline, and do your people feel like they have been treated fairly?
To answer the first part, ask yourself seriously: what happens if we don't hit this deadline? Does it truly impact the company and/or team, or does it impact you?
I've seen many a time when deadlines are touted as hyper-critical, but have minimal actual business impact. They were hyper-critical because it was critical for the manager to get it done on-time, otherwise he/she looks bad. This is not something I would normally presume about a manager, but you've already demonstrated some misguided overly corporate buzzword-notions in your post.
I personally am much more likely to trust my manager's prioritization of tasks (and thus, deadlines) when I feel that he is looking out for the team (or hell, the company) rather than himself.
sorry - English is not my first language. (Not fixing the comment to keep yours relevant)
I think my question is being taken the wrong way. Let me try asking again: I have work X to get done. I have a team member who I would like to work on this. I ask them to estimate the work, validate the estimates and then track against the same. In the weekly status calls, if they are behind schedule, can not give a justifiable reason for being behind (like personal reasons, unexpected technical complexity, hardware issues); how does the group manage?
I think my question is being taken the wrong way. Let me try asking again: I have work X to get done. I have a team member who I would like to work on this. I ask them to estimate the work, validate the estimates and then track against the same. In the weekly status calls, if they are behind schedule, can not give a justifiable reason for being behind (like personal reasons, unexpected technical complexity, hardware issues); how does the group manage?
Your questions look pretty valid to me. It's a shame that the language barrier leads to down-mods. Especially, considering that you are making the effort and speaking their language in the first place.
(English isn't my first language either.)
(English isn't my first language either.)
If you know developers X and Y aren't hitting their deadlines, then a weekly status call isn't enough. You will have to micromanage; this means at least daily one-on-ones, seeing with your own eyes what was produced, testing their finished products, and discovering _what is wrong with them_.
In me experience, poor performers aren't lazy. They either have personal problems, or burned out, or need something but are afraid of asking because, ironically, they thought it would make them look bad.
In me experience, poor performers aren't lazy. They either have personal problems, or burned out, or need something but are afraid of asking because, ironically, they thought it would make them look bad.
The company I work for had a strong bias towards PMI-ish project management. Once I was discussing some allocation issues and the project manager said we should allocate more "Java resources" (despite the fact the product in question did not use any Java code).
I fired back with a recapitulation of all the "resources" allocated to the project, the "PHP resources", the "design resources", the "testing resources" and, when it came to count him, I mentioned one "powerpoint resource".
It took him about 5 seconds to get the joke.
I fired back with a recapitulation of all the "resources" allocated to the project, the "PHP resources", the "design resources", the "testing resources" and, when it came to count him, I mentioned one "powerpoint resource".
It took him about 5 seconds to get the joke.
heh, sure. I see how my comment is coming off as bitchy and is being downmodded. However, I am genuinely curious. There are people in my team that are currently just working 9-5. There is one guy who is working nights and weekends because he likes it, and then there is one guy that's working (productivity wise) 25-30 hrs a week while missing internal milestones.
Its frustrating to be in my place, because I feel sad for the nightouter when he picks up for the third guy
Its frustrating to be in my place, because I feel sad for the nightouter when he picks up for the third guy
> "because I feel sad for the nightouter when he picks up for the third guy"
Why not talk to the night-coder? The best bosses I have ever had were the ones who actively told me to work less. It's so rare to hear that in our industry that you may just earn yourself some real loyalty.
[edit] To clarify: the guy not pulling his weight is IMHO a separate issue from the guy who works at night. If the guy not pulling his weight is forcing other people to work more though, by all means don't let that happen. Then you have two problems on your hands instead of one.
Why not talk to the night-coder? The best bosses I have ever had were the ones who actively told me to work less. It's so rare to hear that in our industry that you may just earn yourself some real loyalty.
[edit] To clarify: the guy not pulling his weight is IMHO a separate issue from the guy who works at night. If the guy not pulling his weight is forcing other people to work more though, by all means don't let that happen. Then you have two problems on your hands instead of one.
Ah, thank you. Now I feel we are on the same page. The nightcoder- talking to him is something I was not considering so far, but now am.
Could we also talk a bit more about the problem I was trying to get around to - how do you solve the second problem? How do I 'by all means don't let that happen'?
Could we also talk a bit more about the problem I was trying to get around to - how do you solve the second problem? How do I 'by all means don't let that happen'?
You confront him.
It may make you uncomfortable but it needs to be done. You need to be up front with him and say that lately his performance has been unacceptable and that he needs to correct the situation.
Being honest about it will often fix the problem.
From your vocabulary and planned milestones and weekly status meetings I'm assuming you work for a large company. If he continues under-performing without valid reasons you start the process your company has for getting him fired. You call him in to your office to issue a formal warning with a copy given to HR and explain to him that he's on the path to getting fired if he still doesn't correct the situation. Depending on your company policy you can usually fire after 2 or 3 documented warnings. After the warning, if he still doesn't do anything about it you start putting out job offers for his position.
It's the only way his performance won't sap the energy of the entire team.
It may make you uncomfortable but it needs to be done. You need to be up front with him and say that lately his performance has been unacceptable and that he needs to correct the situation.
Being honest about it will often fix the problem.
From your vocabulary and planned milestones and weekly status meetings I'm assuming you work for a large company. If he continues under-performing without valid reasons you start the process your company has for getting him fired. You call him in to your office to issue a formal warning with a copy given to HR and explain to him that he's on the path to getting fired if he still doesn't correct the situation. Depending on your company policy you can usually fire after 2 or 3 documented warnings. After the warning, if he still doesn't do anything about it you start putting out job offers for his position.
It's the only way his performance won't sap the energy of the entire team.
Unless the project is the Apollo-11, I have never understood why 9-5 is not sufficient. That's 7 solid hours of work (1 hour for lunch). If pointless meetings consume a lot of that time, I get that may not be sufficient.
Personally, whenever I've put in 7-8 solid hours of coding and/or design/thinking, I'm spent for the day. Done. Over. I just want to give my brain a rest at that point. I don't think it's humanly possible to be working at peak capacity for anything before 10 hours a day. I wish modern workplaces focused more on how to create an environment/culture where employees are in "the zone" more often than just having them put in longer hours. That I believe would produce higher quality work.
This whole thing about expecting programmers to work beyond 9-6 is just sad. I have never once seen a Product Manager or Business Dev guy work late into the night.
Personally, whenever I've put in 7-8 solid hours of coding and/or design/thinking, I'm spent for the day. Done. Over. I just want to give my brain a rest at that point. I don't think it's humanly possible to be working at peak capacity for anything before 10 hours a day. I wish modern workplaces focused more on how to create an environment/culture where employees are in "the zone" more often than just having them put in longer hours. That I believe would produce higher quality work.
This whole thing about expecting programmers to work beyond 9-6 is just sad. I have never once seen a Product Manager or Business Dev guy work late into the night.
It is impossible to estimate accurately. I read somewhere which seem quite valid - "if we can't predict how much time was spent developing something even when we have the finished product at hand, what chance have we got of estimating something that is still up in the air".
About managing people, the best you can do in your situation if you really care is to inspire those you think are not performing as well as they could. Explain how working passionately will ultimately benefit them. Of course, treat them as human beings first and not as resources.
About managing people, the best you can do in your situation if you really care is to inspire those you think are not performing as well as they could. Explain how working passionately will ultimately benefit them. Of course, treat them as human beings first and not as resources.
I'm not sure I agree with the estimating thing. Though I've only met one developer/manager that is good at estimating. He works at a steady pace and doesn't cave when people want things faster. It's tough at first but once you deliver on time, they respect your estimates.
He's also the only guy that I know that buys new cars with cash. He just puts away a "car payment" every month. When the old car wears out, he buys a new one.
It's tough to manage people that aren't pulling their weight. Take time to listen to what signals they are giving. If they want to work, help remove their obstacles. If not, do what you need to so the productive people don't get dragged down.
He's also the only guy that I know that buys new cars with cash. He just puts away a "car payment" every month. When the old car wears out, he buys a new one.
It's tough to manage people that aren't pulling their weight. Take time to listen to what signals they are giving. If they want to work, help remove their obstacles. If not, do what you need to so the productive people don't get dragged down.
There are people in my team that are currently just working 9-5.
Were they hired with the expectation that they would work longer than that? I ask because it's not unheard of to be told you'll be working one set of hours, and then expected to work something completely different.
If no expectations were set at all during the hiring process, that's more the company's fault than the employees' fault.
Were they hired with the expectation that they would work longer than that? I ask because it's not unheard of to be told you'll be working one set of hours, and then expected to work something completely different.
If no expectations were set at all during the hiring process, that's more the company's fault than the employees' fault.
I think that he's more concerned with dealing with the guy that is not pulling his weight, not with motivating the 9-5'ers to work overtime.
More than once I had a wish managers would have read this book: http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
When I was made a manager, I had the company buy cases of that book: one for each person in the department.
As a former developer turned manager turned developer again, a few suggestions:
1. Never lose your developer mindset. Personally, I have great difficulty respecting a non-technical manager of technicians. I bet I'm not the only one.
2. Manage things. Get good at project management. Very good. A good plan, agreed upon, well built and administered, will always be your friend. Something for everyone to fall back on when things get hairy.
3. Don't "manage" people, lead them. Preferably by example.
4. Everyone has problems. Now that you understand that, don't let people's problems interfere with their work or nothing will ever get done.
5. Learn the difference between issues and details. Focus on the issues. Don't waste too much time on the details. And get your team to do the same.
6. When all else fails, communicate. When all else goes well, still communicate. Never underestimate the power of communication. You'd be surprised how much slack others will cut you if you're simply open and honest with them.
7. Treat everyone else the way you'd like to be treated. (This goes for everyone, not just managers.)
8. Listen at least as much as you talk. (This also goes for everyone, not just managers.)
9. Get stuff done. And have fun doing it.
10. Lighten up. You'll be fine.
1. Never lose your developer mindset. Personally, I have great difficulty respecting a non-technical manager of technicians. I bet I'm not the only one.
2. Manage things. Get good at project management. Very good. A good plan, agreed upon, well built and administered, will always be your friend. Something for everyone to fall back on when things get hairy.
3. Don't "manage" people, lead them. Preferably by example.
4. Everyone has problems. Now that you understand that, don't let people's problems interfere with their work or nothing will ever get done.
5. Learn the difference between issues and details. Focus on the issues. Don't waste too much time on the details. And get your team to do the same.
6. When all else fails, communicate. When all else goes well, still communicate. Never underestimate the power of communication. You'd be surprised how much slack others will cut you if you're simply open and honest with them.
7. Treat everyone else the way you'd like to be treated. (This goes for everyone, not just managers.)
8. Listen at least as much as you talk. (This also goes for everyone, not just managers.)
9. Get stuff done. And have fun doing it.
10. Lighten up. You'll be fine.
your number one task as a manager is to find suitable sub tasks a developer can estimate on. this implies that you actually know your developers and their skills and give them only the amount of work to judge on they are comfortable with. i can judge on a project that is worth some months of work easily, a junior developer probably only looks about 2-3 days ahead.
a)estimate right when given the chance,
First look up the definition of "estimate".
Second the shorter the estimate the more accurate it will be. So, I a developer says I can do this in a day that's probably mostly right.
But if he says that he can build something in 3 months, that's most definitely wrong.
First look up the definition of "estimate".
Second the shorter the estimate the more accurate it will be. So, I a developer says I can do this in a day that's probably mostly right.
But if he says that he can build something in 3 months, that's most definitely wrong.
Why has it taken so long for developers to figure this out?