271–280 of 286 posts
Earlier quoted context omitted.
which is why blogging this is dangerous for him. First off, it his team reads it what will they think? He is inadvertally calling out problems with his management team and got a lot of exposure.
honestly, i'd love to have this guy in my team at Microsoft. its good to have a reflective nature on what's not working.
Earlier quoted context omitted.
which is why blogging this is dangerous for him. First off, it his team reads it what will they think? He is inadvertally calling out problems with his management team and got a lot of exposure.
honestly, i'd love to have this guy in my team at Microsoft. its good to have a reflective nature on what's not working.
Honesty should be encouraged specially in big environments, since it finds the pains on the middle management that normally does not show up anywhere.
Earlier quoted context omitted.
Although things were done differently than they are done in Silicon Valley, the difference is not necessarily bad, perhaps more eye-opening. This is how MOST computer science majors spend their careers. Not mastering MongoDB, collaborating on Google Spreadsheets, or posting things to HN, but using Windows XP, Visual Studio, and Microsoft Word 2003 on a 2008 Lenovo laptop. And MS is perfectly happy taking their money.…
It's curiosity that's important, not new stuff. We read HN because we're curious, and we don't want to miss anything. We don't get stuck on old inferior tools (at least not at home) because we like to tinker and explore. You can judge people, to some extent, based on their reading, their tools, how informed they are about the competition. Programming is like surfing a tidal wave of information and change; you don't i…
It's shocking how many of my team mates haven't even heard about Scheme, let alone tried to learn it. And yet learning that language (I'm still working on it) is revolutionising the quality of my code. There's a lot of important stuff that was developed years ago that's just as important as stuff that's coming out today.
Earlier quoted context omitted.
I'd say that's implicit, if code that doesn't deliver business value (refactoring, documenting, etc.) is wasted, people won't do it.
I don't think code quality and documentation quality are strongly correlated, they are just complementary.
I'm not talking about giving a manual for every piece of code you write, but any code that will be used by others (specially in big companies) should be well documented.
If good code is not documented, it will probably cause the same amount of trouble for people using it, than a bad piece of code.
People often forget that their code normally ends up outliving them.
Earlier quoted context omitted.
I agree if you're working in some drone farm. Without a personal stake, why do people feel enthusiastic about following orders that keep them locked up at work all day? I understand that there may be coercion, like the threat of being fired, but if you're just writing software for your company, where does the enthusiasm for long hours come in? I'm freelance, and I love working on my projects. I often work long hours.…
Sometimes I work noon-10pm at Google. Because I feel like it. What's the problem? :-)
Earlier quoted context omitted.
Well, honestly, working past 6 all the time should be considered absurd (assuming you are arriving at work between 7 and 8). I understand the benefit of hard work but I see too much youth wasted on free labor given to corporations.
Arriving at work between 7 and 8? Are you crazy? I don't even get out of bed that early. ...on the other hand, I think 10 AM - 6 PM is a pretty reasonable work day.
I'm not sure where to start. This is a person at his first job out of college and he's been there for less than a year (two if we're being generous). And yet he has the audacity to say "I learned that one will see this sort of problems in all large scale companies."? Really? This is absurd. I can't wrap my head around the sort of arrogance and myopia that makes a 21 or 22 yr old think that he can describe an entire w…
Hey there, author of the post here. I thought I may justify what I said. I have friends in almost all big companies and I discuss them about these issues a lot. Almost all of them agree that they are in a similar situation. I know that even Microsoft is a huge world and NOT all organizations are the same. All organizations have their own culture so there's no common culture in the company I can describe. In a way thi…
As you get older, you'll find there's a stark difference between first & second-hand experience.
Earlier quoted context omitted.
> Are you fucking kidding me? That's what 21 year olds do. Not all, i have the pleasure of working with some 20-22 year olds who would be very unlikely to make such a statement.
Sure, not all. That goes without saying as the intended meaning for every* use of "everybody", "nobody", "every", "all" etc in normal conversation. Those are statistical qualifiers, not absolutes. (*well, almost every -- which reinforces my point).
Earlier quoted context omitted.
Sure, not all. That goes without saying as the intended meaning for every* use of "everybody", "nobody", "every", "all" etc in normal conversation. Those are statistical qualifiers, not absolutes. (*well, almost every -- which reinforces my point).
Thats why i personally try to not used absolutes conversation, because some people do think like that where of every X is Y.
Companies like this already have extensive internal ecosystems of tools. These tools were built to work together with other company systems, they adhere to various internal development standards, have teams dedicated to supporting and enhancing them, and are already known and trusted by other engineers and management.
For any problem you are likely to encounter as an engineer, there is typically an existing system that already does what you need, or close. This tool can quite probably be improved or reconfigured to do what you need with less effort than it would take to bring in an outside tool and make it fit internal expectations.
Because of this, the smart bet is usually to use or extend existing solutions rather than exploring and importing new ones. And really, just learning all about the internal systems is a job in itself, quite enough to sate the curiosity of nearly anyone.