"This kind of thing happens all the time"
Perhaps this is why he is standing up against this?, perhaps he thinks that someone's got a put an end to all this and that he must take matters into his own hands?
My point is that math professors as a bunch put up with this kind of stuff all the time because more than half of the incoming class is just going to be horribly unprepared for any kind of graduate work. Are the students to blame for being unprepared? Yes, I think so but there is also the fact that universities take on way too many graduate students simply because somebody has to be a TA for all the lower division classes the math department offers. This is just bureaucratic bloat and a byproduct of this bureaucratic bloat is that people who shouldn't get a PhD get pushed through the system because it keeps the attrition rate down, at least on paper. So it's great that this guy is standing up for what he believes in but the problem is more systemic and I doubt his one man stand against one student is going to make much difference to how the universities currently operate.
Not really. For many, it's just that it's not "their thing". More that 50% of the incoming students failed the first semester at the college I attended. Many tried a couple times and then went away to pursue other careers. I would never favor dumbing down the curriculum to accommodate people who want to be professional engineers but can't do math...
One day, I could be flying the planes they designed.
I'm not favoring dumbing down curricula. I'm favoring honest practices on the part of the administration to not overcrowd their graduate departments simply because they have too many lower division class offerings and somebody has to be a TA for those classes. It's unfair to everyone involved and the university is the only one that benefits because they pocket the tuition fees.
If you feel remorseful about self-posting, you can do what jacquesm did in his post about his experience dealing with VC's (great post by the way). He just put the whole thing here.
Typically I don't even notice who posted it to HN unless I've really liked the post and never seen that domain before (and thus wanted to learn as much about that new-to-me site as possible), so I can't say I personally have any feelings on others who self post.
Relying on a small community on some of my blogs to post things I think will be of interest here at HN isn't effective, either.
I like getting as much input and conversation around my posts and posts of my contributors as possible. I view Hacker News as a way to bring new eyeballs in to deserving contributors (the same way I view Reddit and Y!Buzz, depending on the type of post it is).
As an editor of a group blog, I view part of my job is hunting down and finding the right audience for my contributors, and thus have little compunctions posting stuff from my blog that others wrote, as long as I think it has a shot at appealing to the community here.
I normally try to schedule blocks greater than 4 hours for programming and i do everything else on the remaining block of time. This normally requires a little bit of planning the day before and may be disrupted by peers or emergencies, but it works for me.
I strongly disagree with his "developers need to brag" section...in my experience, those developers that brag the most are those whose code is a negative contribution (pardon the oxymoron).
Also, if you're generating a bunch of good code and solving hard problems, people are going to notice you.
Maybe "brag" is too strong of a word, but it all depends on what kind of company you work for. Keeping quiet pretty much ensures that only your peers and possibly your tech lead will know what quality and quantity of work you're churning out, unless they decide to share.
If you're working for a small company where the CEO sifts through source control to see what's changing, producing good code will certainly suffice, but if you work in a large company with a multi-tiered management structure, keeping quiet only pushes the responsibility to promote your work to someone else - and you can't always rely on that happening.
If you're working for a small company where the CEO sifts through source control to see what's changing, producing good code will certainly suffice, but if you work in a large company with a multi-tiered management structure, keeping quiet only pushes the responsibility to promote your work to someone else - and you can't always rely on that happening.
In the cases where you can't rely on that happening, then that means no one else gives a damn about what you are doing. This would be very odd in a multi-tiered organization, since often times development projects are decreed onto the programming staff by strategic direction committees. If no one cares, the project is make-work; warning. Either it is going to contribute next to no value to the organization, or no one has a clue what value it is going to contribute. Either way, you'll be hard pressed to convince everyone who needs to be convinced what you are doing is that valuable.
To borrow a PG idea, to everyone above you in the management hierarchy, you are represented -- as an aggregate of the rest of your group -- by either your lead or manager. A lot of the interaction between your group and the rest of the company will be done by them. They need to be your advocate; if they're not doing that, then your entire group is getting shafted, and need to find a better advocate.
Maybe you're right, but upper management knows what are the critical applications and those who deliver fixes and improvements to those apps, will shine. This happens at big companies too (at least it does in AutoZone, my current work place), perhaps this is the exception to the rule, but it's what I've experienced.
Your results should speak for themselves but not in the way an engineer might think. Your technical expertise or the virtuosity of your software is not relevant to the business at large (though it is relevant to the business at hand).
What matters is the value that your work delivers to the business. If you write software that consistently delivers value and has significantly positive impact, it should speak for you. If you work on unimportant projects with little or no benefit or impact to the company, it will not help you, and you should also wonder why you're wasting your time on it anyways. Certainly when it comes time for the business to execute cost-cutting measures like in times like these, they will wonder why.
Then there's politics which can render all of the above moot. It's unfortunate, but that's how humanity rolls. If you work in a large company and wonder how some totally useless and unimportant projects that cost the business money hand over fist manage to survive even during tough times like these, well, now you know why.
I call this the "degrees of separation" rule. How far is your job from the point where the company makes money. Sales and accounts receivable (as much as we like to make fun of them) are pretty high on the totem pole. After you get past the politics, they tend to enjoy some form of stability. And it's not uncommon to hear of a salesman/woman work 10 years in the same company.
On the other hand if your job is writing software for a widget company than it better be vital part of every widget. You don't want to be the guy that is made redundant because what they assumed was good work contributed nothing to the overall business.
Or what if the good work you did contributed quite positively to the business, but in a way that wasn't directly connected via the dots back to you. For instance, what if you write a kick-ass piece of software that doubles the sales team's efficiency, but no manager ever gets farther than congratulating the sales team on a miraculous performance because the believe nothing behind the scenes changed. What if they continue to believe this, in spite of your appeals that it was your software that helped the sales force along?
A company managed this way is a company that will have little left but a sales and marketing force eventually, because the executive staff will have pruned everyone else as being redundant. Arguably, this could happen even in a shrinkwrapped software company, where the software isn't just a vital part of the business, it is the only part.
Hire someone incompetent, or see someone incompetent get hired above you, you may find you'll be made "redundant" even if you are the last developer hacking on the product. It is employment at the will of your employer, and nothing says they can't terminate you due to their own incompetence.
It's such a relief for those of us who share that fear. I stumbled upon this letter yesterday, it's a complaint that a 98 year old lady wrote to her bank's CEO. (http://www.bellaonline.com/articles/art42630.asp)
These two ladies are an excellent example that age is not an impediment for doing things (or doing something about things...in the latter case).
Hmmm... the Internet seems to have helped develop in me a very strong level of cynicism such that I'd put the chances of this being genuine at < 5%, and the Granny Coder at about 40%
Contrived?,yes, useful?, yes (at least in my experience), do i plan to use that formula in every interaction?, i don't think so, it wouldn't be natural.
Thank you for sharing the example of the kid who "rained all over himself", it clearly shows that exceptions apply.
This was shared by a co-worker due to a problem i had at work, the business and engineers speak a very different language...anyway, the article has proven useful many, many times for me, hope you guys like it.
I read your blog, and i found the idea behind biz teen interesting, but i think you're targeting a rather small market (the world doesn't have as many young entrepreneurs as it needs).
If you don't mind getting an idea from a complete stranger, why not do a social networking app for people within the same age range but focusing on something that appeals to a wider crowd (parties, traveling[backpacking through the world comes to mind], choosing the right school, etc).
I realized that, yet to be honest I'm looking in creating an actual SaaS startup. Something that provides values and that actually solves a problem. Thank you for the tips, I hope your business is doing well.
