LebGeeks

A community for technology geeks in Lebanon.

You are not logged in.

#1 October 4 2012

arithma
Member

A plan to digest ~11,000 pages of technical documentation

http://prog21.dadgum.com/129.html
This page has given me a certain perspective into our craft.

The worst part is that by the time you've gone through all these pages, you've already become outdated. The even worse thing is that you didn't manage to learn anything beyond the API's themselves (apart from anecdotal theory or what not that the APIs arbitrarily abstract away).

Reconsidering, the subject should have been: "No plan to digest..."

Offline

#2 October 4 2012

rolf
Member

Re: A plan to digest ~11,000 pages of technical documentation

Very true "by the time you're done with it, the technology will be outdated".
This is food for thought.

Offline

#3 October 4 2012

Joe
Member

Re: A plan to digest ~11,000 pages of technical documentation

I really enjoy James Hague's blog, although he does have a gloomy view of the programming field.

What I mainly take from his posts is:

  • Favor minimalism[1]. Better hardware is not an excuse for complexity.

  • Never stop learning, or else you won't last in this industry.

  • Learn stuff that matters. Knowing the dark corners of your favorite API is nice. Learning the theory behind it is a much more portable skill.

  • Work on problems you care about.

That last one seems a bit utopic,  but it isn't. When you have a goal (like solving math challenges, developing a business tool, or inventing your own game), you are a bit more liberated from technological obsolescence. From experience, I find that web developers have a nasty tendency to drop whatever technology  they're using to adopt the newest flavor du jour every time something tops Hacker News (raise your hand if you're already thinking of dropping Coffeescript for Microsoft's TypeScript).

Other fields are far more conservative, and righteously so. It's time to start looking at your current tech for a long run. Of course there's no way you can keep up with the constant evolving Cocoa framework. If your Mac isn't going to last 10 years, then you're making the wrong investment.

[1]: I've been wanting to write something about "Minimalism" in software for a while. I just cannot find the proper structure yet. Something about the benefits of running a 100MB operating system, or why I gravitate more and more towards "barebone" programming languages like Scheme and Lua, as opposed to "battery included" behemoths like Python, Java or the whole .Net suite.

Offline

#4 October 4 2012

rolf
Member

Re: A plan to digest ~11,000 pages of technical documentation

Well, regarding minimalism, I'd say advantages are:
- Less things can go wrong
- Less places for bugs to hide
- Usually better performance
- Less lines of codes to read to understand what is happening (hence maybe less documentation needed)
- Since there is less code to maintain, your efforts are less dispersed and more concentrated, which should result in higher quality code.

It's a somewhat self feeding loop: The more minimal your code is, the more time you have on your hands to further minimalize it :)

Basically minimalism benefits the programmer, and by consequence it benefits the user, indirectly, mostly.

Last edited by rolf (October 4 2012)

Offline

#5 October 4 2012

Kassem
Member

Re: A plan to digest ~11,000 pages of technical documentation

I do not think I understand what you mean by minimalism. Could you elaborate please?

Offline

#6 October 4 2012

rolf
Member

Re: A plan to digest ~11,000 pages of technical documentation

Kassem wrote:

I do not think I understand what you mean by minimalism. Could you elaborate please?

http://en.wikipedia.org/wiki/Minimalism

Minimalism = "Less is more"

Applied to coding, the antonym of a minimalist approach to coding a simple website, for example, would be to start by installing Joomla (which weights like 80 megabytes, BTW) and building the site around that.

Maybe you've heard about the "Keep It Simple" principle. Minimalism would be "Keep It Small". It's often similar, but not the same thing.

The (new) version of this forum is minimal, compared to the old one.

Last edited by rolf (October 4 2012)

Offline

#7 October 6 2012

Kassem
Member

Re: A plan to digest ~11,000 pages of technical documentation

rolf wrote:

Applied to coding, the antonym of a minimalist approach to coding a simple website, for example, would be to start by installing Joomla (which weights like 80 megabytes, BTW) and building the site around that.

I see what you mean here, and I totally agree. But, there are cases when minimalism is not the right way to go. For example, suppose you are building an e-commerce solution which involves processing orders, shipment details, then updating the accounting records...etc. One way to do this is that once user clicks on the checkout button the order processing starts, a shipment is registered, and some numbers are sent to the accounting system. Another way to do this is by implementing each part of this system as a separate module that communicate through a messaging system (like SQL Broker for example) and everything would be done asyncronously.

Which option is more of a minimal solution? But which one has better chances of scaling? Which one is easier to maintain? The point I'm trying to make is that what seems to be a complex solution first, could prove to be a much more simplistic one on the long run.

Offline

Board footer