http://theprogrammersparadox.blogspot.com/
Nearly 15 years of writing about most aspects of software development. Not really awesome, but it is my attempt to make some sense out of 30 years of software development.
Location: Toronto
Remote: Yes, preferred right now.
Willing to relocate: Maybe, later, at some point.
Technologies: Go, Java, C, C#, Unix, Windows, etc.
Résumé/CV: https://www.linkedin.com/in/paulhomer/
Email: paul_homer at yahoo.ca
I've got 30+ years of programming/design/managing experience. I prefer algorithmic coding for backends but I have worked in a wide range of different positions, systems, and domains.
Location: Toronto
Remote: Yes
Willing to relocate: No
Technologies: Go, Java, C
Résumé/CV: https://www.linkedin.com/in/paulhomer/
Email: paulwhomer@gmail.com
30 years of experience. Looking for something new and interesting. Prefer backend/systems programming.
It is mentioned a couple times explicitly, but I think most of the readers for this blog would know that the border line for tractable is polynomial growth. Still, it is an interesting observation, worth investigating.
Yes. Theoretically the algorithm is tractable, but the exponent is so large that it wouldn't be practical to run it in a real environment.
Interesting. The boss gives a very specific set of requirements, then the programmer disobeys this direct order, goes behind his back to do it differently and has essentially been lying to him or her for months.
It doesn't matter if it's the right or wrong technology choice, this is really an issue of 'work ethic'. Perhaps if the language was left unspecified, or it was a suggestion to use C rather than a requirement then it might be different, but this sounds like a rather blatant violation of trust based on a lack of respect.
I'd have no problems removing the programmer from the project, even if the software was awesome.
Personally I think it is sad. FB tricks people into paying too much, and then some wealthy guy who should have been able to evaluate the offer properly gets fooled, but because he can afford the loss he tries to justify the whole thing, so that perhaps he can pull the same nasty stunt like that sometime in the future.
Using Cuban's own auction analogy, he was basically defrauded by buying a 'fake' collectors item, and thinks the fault lies with the purchasers (for not recognizing a fake when they see it) not the sellers or the auction house for perpetrating this ruse.
Paul.
And I have a tail-bone, but no tail ...
The world doesn't need 7 billion programmers, and if people really do want to learn programming then they should learn to do it correctly since the world doesn't need anymore badly written software (we have enough already).
Paul.
When I get paid to work I really care that the work I do is worth the money I am paid. That is, if I'm paid for 40 hours, I feel its important to give my employer 40 hours of good solid work. From time to time, I don't mind going above and beyond, things happen and sometimes it takes a significant effort to correct them, a bit of overtime is fine. But I strongly feel that any of those companies that pay people for 40 hours of work, but generally expect them to work 60 or 80 hours most weeks are abusing the relationship on their side. What they are looking for is a seriously large discount in labor costs. Unless there is some 'other' form of compensation that balances it out, then it is clearly abusive (and quickly leads to burnout, so they aren't even getting value for the hours worked).
Paul.
These were really neat machines. When I worked with them, the dominate language was Pascal and I think they were running a version of X Windows (or at least a similarly powerful windowing system). The funnest part was that we had these utilities that would allow you to do things like 'melt' another workstation's screen (this pixels would all start to drop to the bottom of the screen). It was hilarious. PCs in those days just had character based screens and Macs were still B&W. Amigas were the most interesting micro...
I tried at one point to port some software to Amix, way back when it was released. Mostly the OS was OK, but there were some issues with the floating point handling that stopped the port from working properly.
A designer breaking the rules will generally enhance their work. A coder violating an architecture will often just create long-term technical debt, at the expense of some short-term gain. That is, they'll get their piece done faster, but leave in its wake a nasty problem for someone else. Of course that only applies if the architecture is reasonable and its rules are correct from an engineering standpoint. In practice, many of the 'coding rules' are too brittle for the circumstances, thus making things worse, not better.
The difference is that one change is done purely for the improvement of the aesthetics, while the other is done because of some fundamental disagreement about the underlying engineering principles. One change is done irrationally because it "feels" right, while the other is a disagreement on the nature of the rules (or a lack of understanding of the purpose of the rules). But there are rules (whether or not they've been articulated).
Usually when programmers "hack" things, they cause a raft of other problems in their wake. As software development progresses from an art, to a science and onto engineering, hopefully the desire to hack at things will diminish. We can actually reliably build complex systems, but only when we choose to think about the right way to do it, rather than just react to our environment. Personally I don't think good programmers "hack". They build. It's very different.
Actually it is deeper than that. It's really teaching you how to see... (and then draw what you see).
There are "rules of thumb" which nice people have put together, but they are just a starting point. If you follow the rules pedantically or even closely, the results won't be good. They're just hints to get you going. It's not about obeying rules, it's about how it looks.
The book I referenced is a great resource in explaining why this is true. Part of the brain sees things symbolically, so that when someone is drawing a face for instance, they don't draw what they see as the eye, instead they substitute a symbol in its place. To the person drawing this might look OK, but to other people it looks like a kid drew it. To get good at drawing, you have to shutdown that symbolic part of the brain, and just draw what you see, not what you think you see.
Programming and Graphic Design are opposites. Logic, reason and lots of self-discipline makes for good programmers. Art on the other hand is grounded in emotion and perception. It's more about escaping discipline, while allowing yourself to get in touch with some inner irrational being (so that you don't mess up the design with logic and symbols). Art touches you, while programmers build things. Graphic Design in some sense, is just the industrialization of Art for specific purposes (although often less emotional).
It's best to realize that a good Graphic Designer can outrun a programmer in the same way that a good programmer can outrun someone that can't think logically, although some programmers seem oblivious to this. If you need good Graphic Design, it is best to hire a professional that is well suited to the task.
If you really want to try to bridge the two worlds, then a degree in Graphic Design is a good idea. Drawing, painting and photography are also good hobbies that can help you develop an aesthetic. A good reference to start with (and explain why logic and rules fail) is Drawing on the Right Side of the Brain. It's an old classic, but helps in understanding how our brains interfere with our perceptions.
I'm not actually trying to say that programming is the same as typesetting. I just wanted it as an example of a 'profession' that came and went purely because of technology.
That's why I went on to describe a model that could minimize programming and heavily reuse any earlier efforts. It is the possibility that the model is implementable that could cause a major reduction in the need for skilled programmers. Typesetting just lays out a historic pattern.
The stuff I've always liked is usually really obvious. For example, if it's complex tree code, you don't have to spend a lot of time digging into the details; what the code is trying to do is obvious by its steps. Clean, clear, simple and consistent. Boring is an unfair categorization. I meant it in terms of not being clever, but it is really an attribute of the observer, not the code.
The best test I think is in how fast you can make a meaningful change to the code, without having ever seen it or studied it before. In a practical sense, that is the only metric that matters anyways. We write this stuff, so we can maintain it and keep it running. It's not the first version that matters, it's the whole life span.
Oddly, good communication is nearly the complete opposite from good code. Your code should be boring, consistent and obvious. It makes it easier to fix that way. Writing should vary, be inconsistent, approach things from different angles, and often be redundant. It needs to be messy enough to keep the human mind interested; although too many little irritants like spelling and grammar can be disruptive. Some structure is good, but too much spoils the flow. It's a balance.
The deformations are there on purpose, I was trying to give it an edgy style, otherwise it just doesn't appeal to the audience I am trying to reach.
I fixed the other typos, as there were unintentional, just a byproduct of fast sloppy editing :-) It's writing, and it's an opinion, so I rather get it out there with a few typos, spelling mistakes and bad grammar, then just sit on it forever.
(but read my other articles, you know, the longer ones with more detail :-)
Generally, I try to write more formally, but then I often get complaints about being too stiff and too long.
The crazy bit about blogging is that there is at least one complaint for everything you write. Just proves that you can't make everybody happy. Still, I liked it :-)
Yep, it should be wisened. Funny enough, I think my stupid spell checker changed it on me on my last round of proofing. Can't trust these stupid computers, can you?
CTO's come in a couple of different favors, generally ranging from being very technical to be very 'executive'. At worst they're just an extra layer of management, at best they're the visionaries behind the products. Some code, some just talk. The cost for a good one is usually 'equity'.