Thursday, June 19, 2008

Think more, work less

I want to spend more time in front of a white board than a keyboard. My goal in career path is to be a software architect. The problem with architecture is you must have a proven record of success (or at least incredible failures) to get people to listen to you.

Just like buildings, software needs architecture, design, engineering and development. The developer is the hammer-wielding lumber-packing implementor. The engineer takes the design from the designer and makes it work in a physical environment. Engineers have to know how things work. It helps to have been a developer so you can make estimations of time and resources. Also an engineer who knows what needs to be done can make alterations to the design to decrease cost and improve stability. The designer is all about aesthetics. People have to want to live in this thing (or live with it anyway). If it's going to sell it needs to be environmentally friendly and cost effective. Designers take an idea and make it beautiful.

Architects are full of themselves. It's a job requirement. To be a good architect you have to believe that you can dream up something that is better than anyone else's dream. And when you're comparing dreams you don't have anything other than your own ego. You might think that the world doesn't need architects because designers and engineers could just get together and make pretty things that actually stand up (or start up). You're wrong. Architects think up things that haven't been done before. Or a completely new way to do something common. Just like the other positions in the work-to-thought career path the best architect will have started at the bottom and have intimate knowledge of the process. Then the great architect will forget all of that garbage and invent something that no designer, engineer or developer would attempt.

So think big or go home. But don't work with your hands if you can work with your head.

Labels: , , , ,

Saturday, February 03, 2007

Why Programming is So Hard

This is an interview with one of the co-founders of Salon which does a good job of articulating why programming takes so long.

Some of the major points I have found to be completely true:

  • · You can accurately estimate the portion of a project that many people have done already. You can’t accurately estimate the amount of time it will take to do something new.
  • · Programmers can usually write something themselves faster than learning how to use someone else’s system. The only problem is that the product you end up with is rough around the edges. Leaning another system will take longer but may result in fewer bugs.
  • · The best way to create software is always to have just one person write it. It just takes longer.

Labels:

Wednesday, November 08, 2006

Is Computer Science Still Worth It

from slashdot:

"Is it a good idea to go into Computer Science? Yes, there are certainly pending labor shortages as Indian companies outsource to the United States, but speakers of Stanford Computer Forum generally agree that it's a good career choice. From the article: 'To ensure job security, students must learn business, communication and interpersonal skills, Vardi recommended. The personal touch will become as important as technological expertise, he said. "There are jobs galore," agreed Suzanne Bigas, assistant director of the Stanford Computer Forum.'"


This is what I've been saying about the outsourcing issue for a year
now. People who want to work in technical fields shouldn't be afraid
of being laid off if they do something creative or interact with
people in a way that can't be done over the phone or Internet.
Everyone who just pushes buttons is expendable.

So if you're going to get into software development you should make sure you work on your people skills. It might also be a good idea to minor in a foreign language or communications.

Labels:

Wednesday, April 26, 2006

On Game Development by Zach Bronow

I saw this on Slashdot and I don’t quite understand why an article like this was even written. People of the Press such as this seem to treat the initial development vision and feature lists as utter fact and don’t seem to understand that things change during the development process.



Half the information they get from press events where the company actually volunteers information through the fancy presentations which are clearly designed to get people excited and are by no means “promises.” They want the media to get inspired and then go tell the customers what they saw; thus the press does the marketing for the company.



The other half of the information they get is from spying and prying and any hint of information about the product, regardless of how tentative it is and whether it was under NDA or not, they regard as a fact and a promise, and then when it gets changed they say they were lied to.



I could never write about technology, either independently (like this goon) or for the press because I wouldn’t believe anything that the companies say. I’ve learned simply through watching the development processes of videogames that everything they announce is for hype and half of what they announce actually makes it in. That’s just good PR in my opinion…



Consider Fable. Once people had bought the game they realized how much of a disappointment it was, but Peter Molyneux and the company (despite their good intentions initially) were crafty enough to lead even the videogame media to believe, up until release, that the game was everything it was “promised” to be. The game was a sales hit because of the buzz, which seemed to come from the press who have had boners for Peter Molyneux and Lionhead since Black and White 1.



And so I think this is the only reason big companies like Microsoft have bad reputations. They’re the biggest, so they generate the most press and too much information is leaked out that should not be. The press disappoint themselves by giving themselves false expectations, and then consumers, who believe everything they read, see Microsoft as the enemy but aren’t smart enough to either modify the product or switch to another product to suit their desires.



ANYWAYZ it just pisses me off and reminds me why I don’t read tech-news unless it’s so far off as to be dreamlike or of a product that has already come out so that all the facts are true.

Labels: ,

Friday, December 02, 2005

Favorite new features in Visual Studio .NET 2005

Work sent me to Microsoft's Launch Tour 2005 on November 29th at the Washington State Convention Center in Seattle. It was probably the geekiest event I have yet attended. I mean I went to the AMD vendor expo a few months ago and it was no where near as geeky as this one. I'll spare you the ugly details (like this group of gothed-out programmers talking about the new Windows Server, or the fact that I only saw 3 women at the entire event and they looked like men).

After getting my badge and goodybag I went to the vendor room and met a few of the local user groups. I didn't know there was a .NET user group in the area but there is. When I'd accumulated enough fliers to build myself a paper V8 engine I went to check out the Web Development demonstration. Basically the guy demonstrated how to open Visual Studio, click New, Web Site, type some text and then drop a few page elements on the designer. I'll admit there were some interesting hints about improvements in memory management from 2003 but it was all stuff I learned reading the docs when 2005 was in beta.

I left the lecture early and went down to the "Ask-The-Developers" area. I wasn't looking forward to trying to explain what I wanted to know to some sales person but luckily the first person who came up to me had a nametag which read ".NET Web Development Team." Turns out he had been on the development team who did the web dev module of VS2k5. Here are the answers to my questions:

Favorite Feature 1:
Abstracted event handlers. I was a little bit concerned when I generated my first new web app in 2005. All the built-in event handlers (On_Init etc) were missing. I had read about partial classes and that code could be hidden from the editor in a subclass but this was not the case. This guy from the dev team told me that all those extra event handlers have been abstracted back into the framework and are no longer visible in the interface. You are still free to overload them if you wish.

Favorite Feature 2:
Web site publishing. In 2003 I had to build my site on the test server then copy the libraries and interface files over to the production server manually. In 2005 there is a Copy Web Site option which takes the current state of your web application and copies it to another location (via UNC path, FTP, or FrontPage Extensions). This copy includes the code-behind source for each page. The other option is a new Publish Site feature which will build the application and copy only the release binaries and interface files over to the production system.


Overall Visual Studio .NET 2005 has made major improvements. Intellisense works on everything now instead of just some of the objects. The interface is much more intuitive: left/right arrows for tabs have been replaced with a dropdown menu, dragging panels around no longer involves guessing where it will land because of excellent colored drop-points. There is a new mini-IIS that gets started when you build your webapp on the test system and stops when you stop debugging. This takes the pain out of keeping IIS on my laptop when all I want is to test a simple app and then copy it to a real server. And finally, even with all these new features and pretty buttons, even though it uses more memory than 2003, it cleans up after itself beautifully.

Labels: