Real geeks die early
norbu09.org
norbu09.org
EDIT: Yep, http://norbu09.org/css/screen.css:
#content p {
line-height: 140%;
letter-spacing: -0.03em;
}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 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.
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 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.
That said, maybe that's acceptable to you. Maybe you're going for a certain aesthetic.
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."
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?
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.
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?
First step: stop calling people "resources"
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.
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?
(English isn't my first language either.)
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.
Its frustrating to be in my place, 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.
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'?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.