More about C++ and programming

What is this? Yet another post? This quickly after the last one? Most people surely most have *completely* missed that I have posted something anyways :) Well, bad bad jokes aside. I remember one more major thing that bothers me about C++ and other languages. I think that it might be related to static vs. dynamic, but I'll leave *that* discussion for later. Here it comes, hold on to your hats ladies and gentlemen...

Change.

Yeah, it is that simple. C++ hates change, it breaks and creeks and the architecture gets stale and bad bad bad things happen. It is really closely related to the last post, because it is about fighting the language. The problem of the problem is that almost always you loose. Refactoring turns into a nightmare. Most often because of management (The Management, a.k.a. the root of all failures), second most often because of the language, and only a few brave and lucky make it in the end.

A language should be ready to be the instrument of molding your solution into whatever it needs to become, an ever changing dance between new problem and new solution.

I am looking at Obj-C, Python, Lisp, etc because of exactly that. We'll see where my journey takes me :)

What makes C++ wrong?

So, what is it, in my humble opinion, that makes C++ wrong then? It is not something specific in the language, even if I am sure one can discuss particulars for days on end:) It's all quite simple, when you step back a few steps and look at what happens when you develop in C++ one can notice that there are two different activities. Solving the problem at hand, and fighting with the language. The first one is vital to any programming, it's the very point of it after all. It's what you should spend time on, and that is what makes it all worthwhile.

So what is that second thing? Fighting the language? That is everything you do that doesn't really solve your problem, but rather the language getting in your way. It's stuff like compatibility issues, low level technicalities, compiler peculiarities, refactoring woes, and the list goes on. I am sure that most C++ developers could collectively make it a huge and comprehensive list. I won't, I will leave that up to you dear reader:)

So the problem with C++ is that I am fighting it more than I am solving my problems. I am sure all languages involves some fighting, the question is how much. I will leave the subject prematurely without any proper analysis or similar, because I want you, the poor sod who decided to read my blog, to think about this yourself and form your own opinion.

Myself I am happily going to discover how much fighting I will have to do with Obj-C, Python, Lisp, etc. I am happy that I do know C++ though, because it has made me a battle hardened veteran in the legions of the Code Marines. I feel confident that I can be victorious in any future battle now. I fought the battle of the valley of C++ and I survived!

Why do good engineers work for bad companies?

Time for *gasp* another post again. I've had tons of things to blog about, yet none I have written down. But now it's time again. The basic idea is that the majority of developers out there seem to be quite frankly bad engineers. They don't care about neither the art nor the product. They are there for the money and honestly could care less. It is not them that I am going to discuss today, I will leave them be to fend for themselves. The group I am interested in is the good engineers. So what the heck do I think is a good engineer then? Let's see.

A good engineer cares about the art, about state of the art, and balances that with the product to find a sweet spot where you are proud of what you have achieved. A good product by good engineering. It has a certain beauty, a certain simplicity and ingenuity. It serves a purpose and does it well. All good engineers have an idea of this, even if it differs from person to person exactly how to achieve it and what the end result should be. So let's focus on these good engineers, those who make a difference.

Next let's define, for the sake of my ramblings, a bad company. A bad company is led by those who do not know nor understand the product they are making. They are very much in it for the money. They might be bad, they might pay good, but they do not care about what the engineers think. More often than not the care more about getting corporate jets, mistresses, reenacting German dungeon porn, living in luxury, shorting schedules, make wild claims, change the product, and put their noses where they do not belong. Simple a pretty crappy environment for a good engineer.

So why do these good engineers work at companies that really only destroys the chances to make great products? We all know the companies, so I won't start to enumerate the worst cases even. I have a few theories. One is the money/laziness theory. They stay because they are good engineers, but lazy. They stay for the money and they don't want to move. They might be bad at getting connections to get new jobs. Basically they need a kick in the butt to vacate the bad company and move on.

Next we have the ones that care about the product and wants to make it great. They are filled with ideas and good engineering principles and knows how to do the right thing™. Management on the other hand do not and constantly tries to save a quick buck and ends up with a much worse product. They have impossible short schedules and requirements from hell. The engineer on the other hand really want the product to be great, so they stay and fights management and turns more and more bitter and jaded. This category of engineers needs to realize that things are never going to change for the better at a company like this, or the chances of it happening are very slim. For every Apple rising out of the ashes there are tons of companies that do not. Again these engineers need to jump ship and move on!

Those are my two, to date, theories. I am sure there are other theories and I am very interested in them, so you have to tell me:)

Oh, and I almost forgot something, you have to make money after you have left the bad company. So how to find a good company? Really research what the board of directors is up to, make sure the company really knows what they are doing, talk to their engineers to see if they are jaded and bitter or energetic and hopeful. Don't sell yourself to a bad company again!

The other option (besides your parents basement, cold pizza, and the lamest computer game on earth all day) is to have an idea you believe in and start your own business, and only hire good engineers (leave the bad ones to the bad companies...). Probably harder, but the rewards all the sweeter!

Good luck all good engineers and let the comments in :)

Ramsay's Kitchen Nightmares

Ramsay's Kitchen Nightmares. What the heck does *that* have to do with anything? Well, for starter's it's called "Den elaka kocken" in Swedish, and I see no reason to call it "The mean chef" really. The guy is not at all mean. In fact, he really does these people a kindness others have never before shown them. He tells them the truth about themselves and what they are doing, he gives them perspective, insight, and help. But again, what is this all about? John! You scream, why-ever would you bring up a TV show in your blog? Well, let's get ready for a ride.

The basic idea of the show is that Mr Ramsay is suppose to help a restaurant and its owner get back on track. The thing is, apparently, the owners and staff doesn't always seem to get out of their established, and quite frightfully bad, ways of doing things. They oppose the quite sound advice of someone who clearly has succeeded better than they. The bright lot of you should by now have an idea where I am going with this. And if not, good luck at the show when you can. It was quite entertaining:)

So, does this sound familiar? Can you draw some parallels with another certain industry? Yes you can. Countless are the times I've had to endure a young whippersnapper trying to tell me that I am wrong about it all and that surely isn't right and you should just chucked all of that stuff out and I know that this and that technology is useless and this other one surely is the way to go, blah blah blah. You know the drill, right? I've got nothing against new ideas, nor being proven wrong. But step one will always be to gain my respect. Listening to someone with more experience than yourself, and take in what she or he says, before starting to complain and wanting to change things, are a good way to to gain my respect. So is proving that you yourself has experience and talent.

But I got side tracked (blog, why blog, why not webbump? web brain dump:) ). The idea stuck me while I was watching the show. This is exactly what a lot of software companies need. They are going about making software in the complete wrong way, and no languages, development philosophies, nor restructures can help me. Hiring even more people will definitely screw them over. So what do they need? They need someone to come in, open up their eyes, and give them some tough love, some sour medicine, some understanding of what they do, and most importantly of it all. Guidance and help to bring them onto the right track again.

I don't want to lessen what Mr Ramsay does in his show, but getting a bunch of Grinch like software engineers to see the error of their ways is seldom an easy task. Nor is it to upset a bunch of frighten school children, I mean managers, nor a number of Scrooge McDuck copies in upper management. Especially from the inside. It is an eternal uphill battle, fought tooth and nail from a position of close to no power, with the only tools to your disposal being your perseverance and your believe in there being a better way.

Not that this is anything new under the sun, but that show just really hit a note in me. What if one would do exactly that, but in a software company? I think that it would be totally great, and oddly enough, I would want to do it. I could imagine myself being that very person, going in there, screaming and muttering and pointing things out, only to have people miss me when they understand how much better it can be. How stress, missing bits and pieces, chaos, and a lack of fulfillment doesn't need to be the standard operating procedure in a company.

So with this, slightly confused professor like, rant I will leave you to think, comment, and maybe blog yourself, on this very broad subject. It is not just what you do, but how you do it!