A lot of the posts here are correct, even the contradictory ones, because the field is so broad.
I’m wondering if there’s any difference in the underyling abilities of people who are good at ‘computer stuff’. Grammar isn’t non-mathematical, it’s based on rules, and logic, just as the basic math used in the development of software is. Perhaps there aren’t different types of people in this field, but people who have developed the same core skills in different ways.
But clearly people who can’t think logically, and can’t apply logic, can’t develop software, but they have management as a fallback career.
I think the absolutely most important part of making software (not necessarily “programming”, but making a finished software product) is interaction design. That’s more psychology than anything else, IMO.
Oh god. Let me guess, he’s probably one of those software engineers that doesn’t have time for little things like thinking through what he’s going to do and prefers to go on a multi-day coding bender. You know, where he thinks he’s doing the right thing banging out code hour after hour days on end and all you can think to yourself is “It would have taken you less time to do it the right way.” or “Why didn’t you think about it first?” (I say bender because the way some people go at it, it strikes me as a junkie that needs to get his “fix” of coding and not somebody that’s actually trying to solve a problem.)
Yes. Entirely true. And there are a lot of programmers who are at least competent at the more problem-solving (that is, mathematical) aspects of programming, such as algorithm design, finding the best trade-offs, and so on, but who shouldn’t be trusted to design a UI for the average person. (Creating a UI for another programmer is another matter entirely; suffice it to say, anyone who thinks standard vi is friendly isn’t going to have much overlap in tastes in UI design with the average person.)
Hey, programming a giant system doomed to fail because you haven’t thought it through can be fun and edifying.
Okay, you shouldn’t do it on company time. But I’ve learned a lot by playing “code some stitched together abomination of a system with no planning” at home for fun.
By coincidence, I just proposed doing precisely that on company time. It’ll be quicker to build something quick and dirty, that probably won’t work, and measure how it fails, than to try to plan an ideal solution up front.
There is merit to that method. I think it really depends on the application. When I’m making an application or something for a specific purpose I usually plan it out. It’s never perfect, but I find it saves time.
For research, or programs where you’re trying to break new ground, it’s going to go through so many rewrites and prototypes anyway that there’s basically no point planning out the suite aside from a few steps in advance. In those cases I usually just sit down and let it burn, then rebuild it from the ashes.
Maybe but like you say, you shouldn’t be doing it on company time. Also I’m also complaining about people who literally won’t stop coding for even 5 or 10 minutes and think about what they’ve seen. (IE They literally produce a stream of code for hours on end. It’s so bad at times my teeth itch.)
H… how do you even do that? Even at my most stream-of-consciousness code ramblings I’m sitting there staring at the screen mulling something over for 15 minutes.
I don’t even know how they can do it either. But when you see code where the person literally wrote the same 10 lines of code 60+ times instead of a writing a function once you know they weren’t thinking about what they were doing.
It’s kind of funny. Runaway, aimless programming is the first step on the way to becoming a great programmer. It’s also the second step on the way to becoming a useless one. You have to learn something the first time you code yourself into a corner.
I always saw the divide as really being “Computer Science” vs. “Software Engineering/Development”, where “Computer science” is the part of it involving algorithm development and proving, and all that business, and the Software Engineering side is the part that deals with taking a problem and solving it with a software program.
They’re more or less lumped together in academia, but in the real world, they’re not often together. Computer scientists typically work at universities and big technology companies, while software engineers are more common and their skills are more broadly applicable in many IT departments and programming shops.
Yup, pretty much. Mostly it’s because one of the big things lately was the code dump they did lately and it was a dump in more ways than one. Still when you’re working with code from a guy who doesn’t believe in source control you know what you’re going to be working on won’t be pleasant.(I could go on about not putting generic clean up code in the base class but I’d just be beating a dead horse.)
Actually what I’ve noticed in my time as a SE is that there’s always one guy like that at every company.(And it seems like there’s only 1, never 2 or 3. Just 1.) I guess the first thing to do when you get hired is figure out who it is and avoid him/her.
Anyway you’re right though, you need to play with your code. Still when you then turn around and do the real solution too many coders take their toy and use it instead of doing a proper solution.(And as you say, you need to learn from your play.)
Haskell and OCaml generally don’t push the Curry-Howard correspondence (which is what you’re alluding to mentioning the connection between programming and mathematics) that far. Coq, Matita and Agda on the other hand … languages where constructive proof and computation merge into essentially the same thing.
Though even for run-of-the-mill imperative languages there’s extended Curry-Howard correspondences where (total) imperative programs correspond to strategies in games.
That is simply a math-centric viewpoint, and incorrect. Math is secretly programmy. Mathematicians (and their cousins the physicists) just don’t realize it.