Dying old beats dying young I guess, but dying sucks overall. The only ones "ready to die" are those where age or illness has already sucked the life out of them. I'm not going to chase the singularity or cryogenics or any other mumbo-jumbo promising eternal life, but heck I hope I'll be like this when I'm 89.

Living in Norway + artificial light + student life with no real commitments I found that my natural cycle is more like 24/12 = 36 hour days than 24. In fact, without alarm clocks I'd have a helluva time staying on the same page as everyone else. The problem is that that sooner or later that clashes with real life and you must get up in the "middle of the night" for a family dinner or you get up in the "morning" and start drinking at a party which messes you up. On Mars making it another 40 mins would be the least of my worries.

The ginormous geniuses I've met don't seem to consider themselves intellectuals, geniuses, or whatnot. I've started pointing out that I'm a genius after recognizing that genius is a matter of technique, and so geniuses can be made: we can turn roughly 100% of the population into geniuses by proper training, with strikingly little effort. As such, one of my future political plans is to tweak the education system to normalize geniuses, bringing the baseline up to something most people believe is an inherent force of genetic superbrainism. Maybe then people will stop pestering me or, worse, trying to hire me with the justification that I'm smart and they want smart people on their team; they have smart people, if they would just act like an intelligent species.

Now, having understood that the only thing that ever stood in the way of my dreams was myself, I must go learn to draw. I realize now that I can't draw because I've never put in the exact same effort that career artists and famous painters put into the subject, and so never learned to draw; it's not that I can't, but that I simply decided not to. That changes now.

A... ah. No, not the one. Not the one, no talk, not the one. The one who will be, but not the one who is; so, not the one.

Well there must be a balance between code reuse and custom solutions. To use the trusty car analogy: a car manufacturer doesn't create a new battery for every vehicle (or, indeed, make batteries at all). Unless it's top end, they don't create a different engine for every car, or a different transmission.

If you're making top-end software, then sure, spare no expense. But most projects will suffice just fine using existing libraries. Knowing when to go third party and when to stay in-house is a skillset that a good lead will have.

If you set up a straw man, then it's very easy to kill it. The issue is not an OS providing something, it's that Microsoft, which had a near-monopoly in the desktop space, used the money from selling the OS to fund development in another market (browsers) and then bundled their version, undercutting the competition with cross subsidies. There was a thriving browser market before IE was introduced, but it's hard to compete when most of your customers are forced to pay to fund the development of your competitor.

Sounds like you've never seen what passes for production code in the bowels of a major corporation. Look at the questions on experts-exchange or stackoverflow. You can safely assume most of them are for paid work. After that, you shouldn't have self esteem issues anymore.

Nothing is better than your own code. But given the choice between my predecessor's hairy ball of custom code and a hairy ball of clue between documented frameworks, I'm not so sure anymore. Because the other side to being generic is "will probably continue to function in a sane fashion if I tweak it a little" while one-off code tends to make a lot of assumptions that may have been true when it was written but falls apart in surprising ways when you try to change it. Unless your predecessor actually made clean, documented code but I know with myself that if you're in a hurry that won't happen. I had to walk a colleague through some systems we use once a year to update various coding schemes and such and to be honest it's an ugly mess. But we do it once a year and we're busy fixing the stuff we use often, so....

A core dump is two projects: find out what's wrong, fix it. You cannot estimate how long it will take to fix a problem until you know what the problem is.

How are you an expert when you consider a core dump to be a reasonable place someone would try to estimate bugfix time from? You can't estimate until you can plan the work, until you can draw a work breakdown structure and show what must be done. Even projects are chartered with a big budget and time estimate based on "this is 3x bigger than something else, so it takes 3x longer and is 3x as expensive", and then broken down into work that all comes together and says "okay, it's only going to be 2.1x as expensive and take 2.3x as long". That initial budget estimate? It comes from a dozen or five dozen or hundreds of prior projects, all with varying times, so you can say, "Stuff of this size and complexity has a low-water mark of like 5, a high-water mark of like 11, and tends to take more like 7.2" and decide how important the project is and thus if you want to budget for more like 5 or more like 11--and the same goes for the broken down work.

You can't even estimate what a bugfix is from a core dump. Someone brings you a core dump and says, "I need a bug fixed." They may as well bring you a blueprint and say, "I need a house built." Until you open the damn blue print up and see if you have a 1200sqft row home or a 4500 sqft Victorian, you have no fucking clue what you're doing, and can't tell them how long it's going to take. Once you unroll the damn thing, you can give them a ballpark estimate by glancing at the paper once; take a few hours to study the blueprints and work out what work actually needs to be done, and you can give them a better estimate.

I have no idea what you're talking about.

Doing it right.

This is a cultural thing. Asian cultures are strongly hierarchical: you always agree with the guy above you. Never argue. You need to either read the cues or break them of that.

Then the people you are working with are stupid.

Get Rita Mulcahy's PM Crash Course (the green book) or RMC Project's CAPM Exam Prep, and the PMBOK 5th edition. Give a read through. Then you'll understand.

A good project manager uses historical data and the expert judgment of the project team to estimate the complexity of the project and determine the time required to perform the work. This is done in many ways: projects are compared to similar projects and scaled to size for a ball-park figure; projects are broken down into work packages, themselves broken down into activities and tasks, all of which the project team estimates the complexity and time required for, accounting for how long it took them to do similar things; time variance from historical data and current contexts are accounted for, providing a low, most-likely, and high mark (2 weeks in the best case scenario; most likely, based on prior work and known information, 3.5 weeks; some disaster scenarios bring in a 9 week estimate--that kind of lag HAS happened).

The more work is done, the more accurate estimates for budget and time become. Agile projects deliver in phases, iterations, and increments, and so can estimate work later in the project based on risk events earlier in the project--opportunities that cut time and can be exploited to cut more time, threats that cost time and may further cost additional time. In this way, "Historical Information" even includes work performance information for the parts of the project already completed.

It's all probabilities.