You could also turn on your (password-protected) screensaver, turn towards him and do nothing except staring at him. (I for one would enjoy his reaction.)

You mean people!

:-D My employer. It's company policy _not_ to telecommute. He probably didn't read that study.

I don't think in this particular case it's the wording. Git uses a significantly different model than most centralized VCSs. Essentially, git doesn't manage versions, it manages patches, and lets you mix and match these at will. While at it, it takes great care to keep a history of all the mixing and matching you did. Now, this pretty much make the notion of a version in the way other VCSs define and use it vanish. And that's where the big problem lies. Head is just a convention, there's nothing that makes head essentially different from any other branch, other than people connecting to a repo designating it as head and the repo forcing you to merge in patches previously merged on head if you want to add another patch. But in the end it's still just a collection of patches. [Off topic from here onwards] The model is quite flexible and powerful, but I don't think there are many dev shops actually needing this power. Your customer doesn't want several branches, he just wants head, so eventually you need to merge every patch into head. Why bother with patch management at its best, then? This whole patch management headache makes sense when you maintain the Linux kernel (quite a few million), receive lots of patches from thousands of developers (about a million lines were deleted/removed or changed from the 3.3 to 3.5 dev version evolution) and have different distros merge and match distinct sets of patches from one version to the next, a traditional VCS won't cut it. IMO, it makes sense to see where you stand between two extremes: the single developer which just wants to track his sources, and doesn't maintain distinct branches, and the Linux kernel. Depending on where you stand, git might absolutely not make sense. Or svn. What I've seen people do is use git for configuration management. This is IMO brain-damaged. Git is a VCS, not a tool for managing binary variants of distinct libs, apps and the like.

The kid in question was probing a service which was making it possible for anybody to find out his personal details. If after being expelled for trying to break into the service a second time he succeeded, I'd argue he has a strong case to sue the college for recklessly and carelessly handling his and other thousands of students' personal data. If I was him, I'd obviously talk to a lawyer.

Or heavy, professional make-up.

Mike Mullikin wrote:

Had a discussion with a co-worker about PC's and this very topic. Open platform... Build your own... Windows runs on it all...
 
If you step back it seems a bit odd that we put this kind of expectation on the PC while we don't on any other products. Automobiles, household appliances, cell phones, etc...

Idunno, it looks to me like there's a moving window of complexity and price, where we do have this expectation. Products less complex and less pricey than those inside the window we expect to be cheap and mostly similar regardless who builds them. Products more expensive and more complex we expect t be costly and have no interchangeable parts. This window continually moves up the complexity and price scale. Which is why I expect we'll get cars built from interchangeable, standardized parts in the next few decades, differing in only a few key aspects (what size of engine the chassis supports or what aerodynamic characteristics the skin has, for example), after which cars will be replaced by some cheap personal transportation device which you won't repair, but throw away when it breaks. Tablets, cell phones or the like will most probably go down this road much earlier - they're simply cheaper.

In itself it doesn't. MS marketing will do this.

I had a handful of different jobs until now, and was a programmer in each of them. I didn't notice that the job title had any influence at all when I went for an interview. I'm a team leader atm, but I still tell everybody who asks I'm a programmer. Nobody in or outside the company seems to give a .

CalculateTax() may be a bad name - it may not be specific enough. It's not that far away from DoSomething(). OTOH, provided it's a private method, used in a context where its meaning is obvious, why would it still need comments, especially if its body reads like return amount * db.GetTaxRate()? Oh, you have GetTaxRate() in the same class, and it's accessing the database directly? That's a clear case poor encapsulation, where two classes, one coupled to the persistence layer and one strongly rooted in the business logic are shoved into a single one, and which need to be separated. I too profoundly dislike comments. I think comments are a code stench (M. Fowler calls them smells, but I think "stench" is more descriptive). Every time I see comments in code I find that they are either useless (the code is quite understandable even without them) or are used to mask other problems (the code absolutely needs some refactoring). Properly maintaining comments anywhere except in libraries which you develop for use across several projects, which you may plan to distribute without source code, is IMO waste, in terms of agile methods, and should therefore be eliminated. Comments are also the source of many stupid problems. Since the compiler doesn't check comments, they tend to quickly become buggy, this being the case especially in heavily commented code. Having been bitten by this many times, I tend to disregard comments, and as such heavily commented code is annoying for me, since I have to skip large portions of prose to get to the parts which actually matter - and which I can actually trust. Also, if you read a C++ header file or a Java or C# class file, and there's maybe 10 lines of comments between any two method or member declarations, you might get a very good understanding of the individual members, but loose the overall understanding of the class you're looking at. This increases the chances of introducing changes which break the overall architectural consistency, or even rightout introduce subtle conceptional bugs which are hard to diagnose. Really, if your code needs commenting, take a better look at it, and think how you can refactor it into smaller, more specialized functions, with better names. Your code should become easier to read without comments if you do such refactorings. And there's a non-documentation-related gain too: you'll notice that code duplication goes down and your code becomes more compact. In his book "The art of Unix programm

I disagree. If the employer paid him to come to work and get busy and spend eight hours a day in the treadmill, the employer is stupid. If the employer paid him just to get the work done, the employer is reasonable. And that's exactly what Bob did - getting the job done. I too think the only issues to consider are those of IP/confidentiality/security. If Bob wasn't working on security-sensitive code, I'd say there wasn't anything he did wrong. And also, even if I'm making a living writing code myself, I consider most code not to be worth not opening (although my employer thinks otherwise). The the companies I write code for don't actually derive value from the code I write for them by selling it, the code is just a tool allowing them to provide a service for which they get paid. The tool is most often so specialized that other companies wouldn't be in a good position to use it anyway. If it's a tool I build, without somebody using it it's worthless. If I find a way to provide my customer with a better tool at a lower cost, should he be angry at me?

As many others have said, learn C++. It most likely won't be the most popular language at any given time in the near future, but if you can program decently in C++ you can master any memory-managed language.

It all depends. What do you value most? I do work on my own pet projects alone, but I value being a member of a larger team, because by confronting your ideas with those of others you learn more and faster than if you just do things yourself. Also, since we are all humans and doing stupid things is in our nature, it might be more difficult to spot errors you do in design/architecture, and consequently more costly to fix. You also don't get the benefit of thorough, specialized testing - at least in my team there are specialized testers too.

Idunno ... IMO any manager who needs to ask his ppl to find out the packing order in the team he manages isn't worth his salt. But then again, I'm frequently and constantly surprised about how little most managers understand from the work they are supposed to manage.

loctrice wrote:

Horrible. Whenever possible, use .Net and/or Java to program for excel.

If it is possible to do your automation solution with OOo, I'd say give it a try. It's scriptable with both Python and Java, not just a VBA-like language (which it does allow, in order to be able to import MSO files containing macros).

It's not just PHP that changes, but also the entire web app landscape as a whole - in fact, it has already changed. There's barely a significant platform out there not having a browser with a powerful Javascript interpreter, which makes HTML5 apps very convenient. Such apps let you move most of your logic to the client. Therefore, I'd not worry so much about the MFC part in PHP - doing UI on the server is sort of anachronic. Instead I'd invest time and effort into getting familiar with one of the more powerful Javascript frameworks for application development out there - I don't mean jQuery, which is just a library for rich web pages, I mean the likes of sencha ext/touch, sproutcore, smartclient and the like. My personal favorite is qooxdoo. In spite of it being a lot less popular than other such frameworks, I think it appeals especially to people coming from C# or Java, but also from C++ with MFC. It lets you develop web apps without having to learn even a bit of CSS, and requires just a minimal knowledge of HTML. This is huge. While all current browsers and JavaScript engines are quite potent at the moment, especially at the CSS level there are still differences you need to know, if you want to build web apps using for example ext. Not so with qooxdoo - it abstracts every possible difference. And it also includes tools which a developer coming from a "respectable" language might appreciate - a unit testing framework, an (somewhat outdated) integration with Selenium for automated UI tests, a built-in linter, a build tool for minifying and packaging applications, a package management system plus a framework for adding contribs - extensions to the framework provided by third parties. It also has a widget library richer than most other such frameworks. And it also has a highly active and extremely helpful community, which never seems to get tired to answer the same beginner questions over and over again.

Idunno about their PHP tutorial, but after reading this about their Javascript, XML, DOM and other such stuff references and tutorials, I'm not comfortable with using that site anymore.

I don't know the code, so I can't say anything for sure. But if I correctly recognize the pattern, the code screams for being refactored into something properly object-oriented - I suppose many switch statements dispatch based on the same variable/set of values. Use extract method to split the large methods, then extract class to extract the smaller, specialized classes, then extract a common interface for all small classes, then change the switch statements to just call a method on an interface. It probably won't be that simple, and also a lot of but not just manual work, but you should eventually get somewhere, IMO.

That's not for bugs, that's a quantitative measure of code quality during code review.

Obviously not - stupidity is highly creative in how it manifests itself ;)