|
|
||
N. Alex Rupp's BlogJanuary 2004 ArchivesDear Alex, tell me the futurePosted by n_alex on January 31, 2004 at 02:07 PM | Permalink | Comments (5)
Friends of mine have said they won't stop writing code until they've re-implemented all of the core unix services in Java. Others have said that until there is an Open Source (non-GPL) alternative to linux that there will continue to be work for us to do, and that once the nature of the GPL license gets tested in court and the public understands more about what it does, they will want to replace Linux with something they actually own. Or maybe not. I don't know the future. I do believe the research however,
If Open Source helps people channel their desire to feel useful and to do challenging and beautiful work until either the economy picks up or they pick up their lives, then I'll do everything I can to help them learn about it and to encourage them to participate in it. The American programmer is my fellow "Forgotten Man". And by Man I also mean Woman. I know too many nice and talented ladies in the field who deserve better just as much as the men. So, you want to know what "exactly" I see in the future. Sorry. I don't see the future--but I do have a poolside view of the present. I see books on Geronimo, Drools, Maven and Groovy coming down the pipe. I see people pushing the bounds of the J2EE platform. I see discussions about replacing servlet technologies. I see Tool designers having their day in the sun. I see a flurry of spontaneous activity. Like insects moving around to warm their hives in the winter, Open Source--as science for its own sake, for the fun of it--has the potential to keep the American programmers warm enough to survive the winter we're entering. I certainly see no reason for intelligent men and women to be contemplating suicide over the loss of a cube. There's just plain more to life than bits and chips. What I don't see is a US bull market in technology in the near future. For all I know we could be looking at Dow 4700 by June and the Nasdaq trading at 18 times earnings. I see that happening. I just don't *know*. I'm not in this field for the job security. I'm in it because I believe there is something big at stake in it. If I wanted job security I would have studied mortuary science. I try not to get too hung up on implementation details (.NET, J2EE, EJB) because those things come and go. I'm more concerned with the overall principles (making information more accessible and useful) and applications (building a network of like-minded people to do business with). There will be no beamings of Scotties unless someone figures out a way to get around the Heisenberg principle. Heisenberg applies to markets, too. As soon as you think you know how the market works, your new understanding of it alters it until your knowledge no longer applies. But, on the science-driving front, carbon nanotubes can be used to make Casimir plates, and there is a potential source of unbounded energy waiting to be tapped--all around us. Nanotech has incredible potential for medicinal uses as well. So nanotechnology will likely *not* be a fad. It's just something we the "unwashed masses" don't understand very well yet . I think the internet will continue growing. Demand for high-speed fiber optics will replace our copper networks It'll take decades to realize that, but it'll happen. I also think that spontaneously evolving P2P wireless networks will probably grow to address our need for mobility until a less expensive way to make and lay fiber networks becomes available. How far this all applies to you and me here in Minneapolis remains to be seen. We have the University as a gateway into nanotech. Perhaps you could look into a full time job there. For the rest of it, I'm no prophet. Just a cold-eyed optimist. Writing software is like driving a bus.Posted by n_alex on January 27, 2004 at 03:25 PM | Permalink | Comments (2)The best software engineers I know make writing code the central part of their day. Like playing a sport or a musical instrument, writing software requires first that you show up. While the three of us were having coffee, a friend of mine once asked Dain Sundstrom how long it would take to become a really good Java developer. Dain's answer was "six hours . . . every single day." You'd be amazed how many talented writers I know who don't succeed at writing (software or otherwise) simply because they don't sit down and write. Ultimately, the results are never as good as you want them to be, and what you want is never as good as people need it to be. So you've got to fall in love with the process as well as the product. You might not get paid for it. But if you love the process you'll get something to sustain you while you learn. You're not guaranteed to get better if you sit and write. But you're guaranteed not to get better if you don't. Also, don't get too attached to your work. You might be proud of it, but don't get so proud that you resist hacking it to pieces in order to improve it. This was a hard lesson for me early on. But now, I've learned to sustain myself creatively by rendering all of my work from the day before worthless, or at least trying to. It means I'm doing my job. I call this practice "eating your babies". Some corporations take this mentality to an extreme and hire a division whose sole purpose is to dream up ways to put the parent company out of business before the competitors do. Then they incorporate the findings into their business strategy. Baby eating requires you to simultaneously be more critical and more forgiving of your work. My two cents on becoming a better programmer: long hours and good-old Jonathan Swift style baby eating. I finally get IoC-3Posted by n_alex on January 27, 2004 at 02:37 PM | Permalink | Comments (2)It doesn't make sense to clutter the action API with accessor methods for these values in a class meant to abstract actions from the framework, so I just have a generic accessor for the mdbean. Then the classes that need it can just pull the values directly out of the MDBean. If there was a way to synch the internal values with the IDE, I'd be set. What I couldn't figure out before was how IoC-3 or "dependency injection" worked with subclasses. But you just have the subclass make a call to the superclass constructor (just like in Matt Albrecht's IFTC test package), which is so simple I had to laugh at myself for not using it earlier. I use interfaces so much that I don't know all the subclassing tricks yet. Every now and then something sneaks up on you that you realize you should have known earlier. Like thread local. And state coupling. | ||
|
|