I would suggest watching his entire talk on youtube: http://www.youtube.com/watch?v=wt-iVFxgFWk
Definitely worth watching. It's more like a tech talk than a keynote. Extremely good insight in there.
John Carmack discusses the art and science of software engineering
31–40 of 74 posts
Re: John Carmack discusses the art and science of software engineering
#32I don't want to be an ass, but this seems like a lot of vague contradictory rambling. Maybe I missed some big ideas in the parts I skimmed?
Re: John Carmack discusses the art and science of software engineering
#33Earlier quoted context omitted.
If I had a dollar for every time I saw this... if(obj == null && obj.isValid()) I'd have approximately 960 dollars per project.
> if(obj == null && obj.isValid()) Why would you encounter this (often)? It seems to me that this code would never evaluate to true.
It's a braino, I think. Instead of the right thing, which would be what mathgladiator posted below, this is a guaranteed null pointer exception when obj actually is null.
Re: John Carmack discusses the art and science of software engineering
#34Earlier quoted context omitted.
The more you know, the more you realize you don't know. That would be a great book though.
I came to that same conclusion a few years ago. Sometime in college I was pretty happy, felt I was making good progression on real knowledge in a field. Now, a few years later - I'm not sure what I know is real and true, which are high order approximations, and which are flat out wrong, but still right enough to not cause too many problems. an example: in grade school you learn how to mix colors, primary colors with…
love this example!
Re: John Carmack discusses the art and science of software engineering
#35Running your code through static analysis can be eye-opening. And just like when you opened your eyes for the first time... you'll probably cry.
Equivalently in a very introspective language, running old code through new unit tests is eye-opening...
Re: John Carmack discusses the art and science of software engineering
#36Running your code through static analysis can be eye-opening. And just like when you opened your eyes for the first time... you'll probably cry.
Static code analysis has a long-term benefit as well as the more obvious short-term benefit. That is, it teaches us to be better developers as we strive to have the static analysis catch less issues in our code the next time [1]. I used static analysis to improve my style for C, Python, and most recently Ruby [2]. I think it had a lasting effect on my personal coding habits. But every once in a while, I will use the…
Static analysis is essential for anything that lives solely in the domain of syntax and style. Detecting bad smells (including duplication and excessive complexity) from when you got tired or interrupted is perfect for it, and is a great heuristic way to find areas that need more attention. In Python and I assume Ruby, anything that bears on function is more reliably detected with unit tests.
Re: John Carmack discusses the art and science of software engineering
#37Earlier quoted context omitted.
If I had a dollar for every time I saw this... if(obj == null && obj.isValid()) I'd have approximately 960 dollars per project.
> if(obj == null && obj.isValid()) Why would you encounter this (often)? It seems to me that this code would never evaluate to true.
This is Java code. If you test for a null reference AND THEN dereference it, you get a NullPointerException. The check was supposed to be "!= null".
This check is obviously erroneous, and found via SCA. I was saying "if I had a dollar for every time I found this [via SCA] I'd have a lot of money."
Re: John Carmack discusses the art and science of software engineering
#38He is definitely right about the social aspect of software engineering. But I think he sells a lot of the tools short. For example, he brings up things like Monads, Lambda Calculus, and whatnot - but then immediately dismisses them as not affecting what one truly does. But I think this really misses the point. In our industry it is really easy to disguise oneself as a professional (or even just someone who knows what…
While I love what Haskell has done for me as a programmer, I don't think that it's finding the true semantics behind our problems. I rather think that it's finding a different basis. To take an analogy, monads and lambda calculus are like Fourier series. For many classes of problems, they produce a cleaner, simpler understanding of the solution. I'd hate to try and solve a boundary value problem with just Taylor series. However, while expressing linear functions with Fourier series is possible, it's less clear than the Taylor series and you're more likely to mess it up.
In the same way, monads, arrows, and recursion are great ways of describing many classes of programs. Additionally, they help with communication when your problem is a monad or an arrow. However, certain classes of problems are better described under other paradigms than being forced into the functional one.
This comes back to Carmack's point. It's important to know Haskell, since it's distilled computation down to a set of elements which are useful for describing a large class of problems. Being able to communicate these solutions is important. However, other paradigms are less error prone and do communicate solutions more clearly on other classes of problems.
Re: John Carmack discusses the art and science of software engineering
#39With the NASA style development process, they can deliver very very low bug rates, but it’s at a very very low productivity rate I wonder how many non-developers understand this. I, along with the rest of my team, am trained in PSP ( http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm ) and TSP ( http://www.sei.cmu.edu/tsp/ ) and we use it in our day-to-day development. It definitely helps us keep our d…
Can you follow up with some information about the (P|T)SP experience? I looked into it about a year ago and thought it was a ridiculous amount of overhead, and the blurbs about the initial data Humphrey used to create it was not persuasive. The "take our class" ads were not encouraging either. So if its working for you in actual development, I'd LOVE to hear more about what it does/doesn't do for you.
First, it helps to understand that even before moving to PSP/TSP, we were already in a process-heavy regulated Medical Device development environment, so it wasn't a big change. My understanding is that many teams starting with TSP didn't have much of a process to begin with.
The good: PSP encourages a high level of developer responsibility for quality. So you use a checklist to review your code before running the unit tests. You record every defect you find and if applicable, use that information to make a better checklist. Every team has a TSP-trained Coach to guide the process, answer questions, and keep the team on track. The metrics generated from the process are analyzed weekly to see if the team is on target, if quality is where the predictions say it should be and if there are any roadblocks.
The bad: it can be a major change to how you are used to working. The data collection, while as automated as possible, is annoying. The constant emphasis on tracking time on various stages of fixing a bug/adding a feature adds a noticeable amount of friction to your workflow. While it's not Waterfall, TSP is definitely not Agile. Its entire focus is on predictability of output. It's an attempt to take what works well for Manufacturing and apply some of that to software dev.
In short, TSP/PSP is a good idea at heart for those types of development where initial product quality is critical or where you may never have a chance to fix a defect. This is not the case for most instances of modern software projects.
Re: John Carmack discusses the art and science of software engineering
#40Earlier quoted context omitted.
The more you know, the more you realize you don't know. That would be a great book though.
> The more you know, the more you realize you don't know. The thing I like about John Carmack is that he really appears to live this through and through. I can't say I know him or have worked with him or anything, but whenever I read something like this of his, I enjoy the fact that it is virtually free of ego and posture. He doesn't proclaim or state - he tries things, explores things, and talks about what he found,…
I submit that Carmack wasn't shaped by the same kind of industry culture that most of the working people on HN were - different time, different kind of software, different funding model. The way our industry incentivizes ego, posture and dishonesty (and punishes the lack thereof) means that young Carmacks either find a rare lagoon, change fields - or get squashed into a different shape. Smart people can still do good work, but the required output is mostly other than technical, and knowledge takes a back seat.
This is what we are spending our lives on!
Finding like-minded people is not impossible, but like-minded workplaces hardly seem to exist. If you are not a Carmack-scale God to create your own lagoon, you literally can't afford just to be straight up about everything. You will fail every interview. That is why this is so rare and refreshing - it is rare because the environment heavily discourages it. Only some people need an ego-oriented environment - but everyone has to eat.
There is actually a parallel in science. People who start out deeply interested in truth and their subject have to exist in an environment which really isn't about those things. They either leave or learn to self-promote, inflate the sizes of their grants and chase fashion rather than bearing down on a particular subject in a disciplined way.
If this culture won't change then we need more lagoons.
In Feynman's words: "So I have just one wish for you--the good luck to be somewhere where you are free to maintain the kind of integrity I have described, and where you do not feel forced by a need to maintain your position in the organization, or financial support, or so on, to lose your integrity. May you have that freedom."