I think it does. True or not, at least people will attach a personality to the blogger based on the blog.
The way it looks...the layout...the author's picture...the text in the about section...the way posts are written...it tells a lot...so be careful.
As examples...guess who's behind...
Green on black. Quick, short and irregular posts on random thoughts on technology and technology meetups. No picture of the author in the about section. The author is...the CTO of a startup...it fits.
Gray on white. Nice but not fancy. Long in-depth posts on heavy technical stuff. Small picture and factual description in the about section. The author is...a tech lead...it fits.
Black on beige. Blue and green background. Pictures of books, albums, writers in the sidebar along with quotes and poems. Regular posts on life, poems, music, books, shows. The author is...a writer...it fits.
Two blogs. Light gray on black and the other black on white. Irregular posts on apparently random topics. No focus. Sometimes in French, sometimes in English. Total chaos...that would be me...it fits.
And what about...
Gray on black. The about section takes half the screen. The description written using the 3rd person and includes superlatives. Posts on business topics. The author is...a CEO looking for a job...yep...it fits.
8/04/2009
7/29/2009
Big Ideas Library
Big Ideas Library goal is to share what digital age thinkers think and read...so you can become a big thinker too and make things happen!
Because we never have enough of great ideas...http://bigideaslibrary.blogspot.com/
Because we never have enough of great ideas...http://bigideaslibrary.blogspot.com/
7/14/2009
10/28/2008
The Montreal Tech Community
You are in Montreal, you love technology, you believe in sharing, openness and community, I suggest you read the following blogs...
http://montrealtechwatch.com/ - by Heri. This is a good starting point to know what's happening in the tech community in Montreal.
http://www.billionswithzeroknowledge.com/ - by Austin Hill, a serial entrepreneur who just launched Akoha.
http://www.afroginthevalley.com/ - by Sylvain Carle, CTO of Praized, a montreal startup.
http://hughmcguire.net/ - by Hugh McGuire, the founder of LibriVox.
And for those who enjoy the juicy technical details of a web server programmer's life, just dive in the deep heap by my colleague Nick Maiorano.
http://montrealtechwatch.com/ - by Heri. This is a good starting point to know what's happening in the tech community in Montreal.
http://www.billionswithzeroknowledge.com/ - by Austin Hill, a serial entrepreneur who just launched Akoha.
http://www.afroginthevalley.com/ - by Sylvain Carle, CTO of Praized, a montreal startup.
http://hughmcguire.net/ - by Hugh McGuire, the founder of LibriVox.
And for those who enjoy the juicy technical details of a web server programmer's life, just dive in the deep heap by my colleague Nick Maiorano.
10/15/2008
A Creative World
Poverty is not only about money...and solving poverty is not only about giving...it is also about sharing.
What if education was global? What if every book was free, accessible to anyone? What if anyone could access, remix and reuse every single piece of work that exists...literature, music, movies,...free of charge!
What if knowledge was global? Patents are about protecting intellectual property...but does it make sense to keep the composition of an important medicine secret...making it impossible for poor countries like India to provide the drug at a reasonable price for Indians?
Freeing art, education and science is what Creative Commons aims for. So the next time you create, why not share it using the CC licenses?
This work is licensed under a Creative Commons Attribution-Noncommercial 2.5 Canada License.
What if education was global? What if every book was free, accessible to anyone? What if anyone could access, remix and reuse every single piece of work that exists...literature, music, movies,...free of charge!
What if knowledge was global? Patents are about protecting intellectual property...but does it make sense to keep the composition of an important medicine secret...making it impossible for poor countries like India to provide the drug at a reasonable price for Indians?
Freeing art, education and science is what Creative Commons aims for. So the next time you create, why not share it using the CC licenses?
This work is licensed under a Creative Commons Attribution-Noncommercial 2.5 Canada License.
7/20/2008
Good Software Engineers
First there was The Dip. It basically says that if you are not aiming at being the best at what you do, you are wasting your time. The big pay-off is only for those who are exceptional. The others are interchangeable. This got me thinking...I'm spending about a third of the week as a software engineer and I don't want to waste that much time, so I better make sure I keep improving in this profession.
Then there was this blog post describing brilliant engineers as Done and Gets Things Smart: "Not superstars: superheroes! People who are freakishly good at what they do. People who finish things so fast that they seem to have paranormal assistance. People who can take in any new system or design for all intents instantaneously, with no "ramp-up", and who can immediately bring insights to bear that are quite simply beyond your rustic abilities." (I don't know if you know this blog by Steve Yegge, but over time, it became my favourite. Yes, the entries are long and the blog is not updated very often...but if you pass that dip, his entries are just excellent.) After reading this post, it was clear that I am not what he describes as a freakishly brilliant engineer and I will never be.
Finally, there was Zen and the Art of Motorcycle Maintenance written around the fuzzy notion of quality and the concept of good. At the end of the book, Chris, the son, asks if it is hard to maintain and take care of a motorcycle. His father answers: "Not if you have the right attitudes. It's having the right attitudes that's hard." I read it at a time where I was slightly bored at work. "The only Zen you find on tops of mountains is the Zen you bring there." And I was not bringing any anymore.
So I was bored and since I'm not a super-hero engineer and will never be, The Dip is saying that I'm wasting my time. Stuck!
But then I thought some more about attitudes and quality. Whenever I create a good piece of software, something with quality, I love it. So I should do just that. I might not be the greatest engineer, but I can be a good one. One that designs good software, one that continuously learns how to inject some more quality into his work, one that has the right attitudes.
I needed a plan, a target. I defined what I thought was a good engineer so I can chase it.
Here it is...the good software engineer defined in three facets. Since I don't think it is possible to reach perfection in any of these facets, it is all about the path up the mountain, not the summit.
Technical Facet
- Needs to know how to program. Not simply how to program Java or C++...how to write beautifully readable code.
- Has to know how to structure software and master design patterns.
- Must know the classic algorithms, data structures and what is a state machine.
- Designs for testability, conceptual integrity and scalability (and possibly reuse).
Soft Skills Facet
- Learns from the past. It is scary to read software books published in the seventies that describes problems we are still living more than 30 years later.
- Is good at explaining ideas and presenting designs.
- Brainstorms and is open to evaluate and discuss eccentric ideas.
Attitudes Facet
- Cares about his work and his colleagues work.
- Aims for quality.
- Irradiates friendliness.
Then there was this blog post describing brilliant engineers as Done and Gets Things Smart: "Not superstars: superheroes! People who are freakishly good at what they do. People who finish things so fast that they seem to have paranormal assistance. People who can take in any new system or design for all intents instantaneously, with no "ramp-up", and who can immediately bring insights to bear that are quite simply beyond your rustic abilities." (I don't know if you know this blog by Steve Yegge, but over time, it became my favourite. Yes, the entries are long and the blog is not updated very often...but if you pass that dip, his entries are just excellent.) After reading this post, it was clear that I am not what he describes as a freakishly brilliant engineer and I will never be.
Finally, there was Zen and the Art of Motorcycle Maintenance written around the fuzzy notion of quality and the concept of good. At the end of the book, Chris, the son, asks if it is hard to maintain and take care of a motorcycle. His father answers: "Not if you have the right attitudes. It's having the right attitudes that's hard." I read it at a time where I was slightly bored at work. "The only Zen you find on tops of mountains is the Zen you bring there." And I was not bringing any anymore.
So I was bored and since I'm not a super-hero engineer and will never be, The Dip is saying that I'm wasting my time. Stuck!
But then I thought some more about attitudes and quality. Whenever I create a good piece of software, something with quality, I love it. So I should do just that. I might not be the greatest engineer, but I can be a good one. One that designs good software, one that continuously learns how to inject some more quality into his work, one that has the right attitudes.
I needed a plan, a target. I defined what I thought was a good engineer so I can chase it.
Here it is...the good software engineer defined in three facets. Since I don't think it is possible to reach perfection in any of these facets, it is all about the path up the mountain, not the summit.
Technical Facet
- Needs to know how to program. Not simply how to program Java or C++...how to write beautifully readable code.
- Has to know how to structure software and master design patterns.
- Must know the classic algorithms, data structures and what is a state machine.
- Designs for testability, conceptual integrity and scalability (and possibly reuse).
Soft Skills Facet
- Learns from the past. It is scary to read software books published in the seventies that describes problems we are still living more than 30 years later.
- Is good at explaining ideas and presenting designs.
- Brainstorms and is open to evaluate and discuss eccentric ideas.
Attitudes Facet
- Cares about his work and his colleagues work.
- Aims for quality.
- Irradiates friendliness.
6/04/2008
Fact-Based Software Development
In my opinion, software development decisions are often based on false knowledge: geek-gossip, guesses, techno-trends.
Recently, I read "The McKinsey Way". The book is uneven; some sections are very interesting, some are close to useless. But I learned that when facing a problem, the best business consultants gather relevant facts first. Then brainstorm to find options. Evaluate, test, and finally, based on the results, select the best one.
This should apply to software development too.
Too often, decisions are taken without (real) fact checking, (real) brainstorming or (real) analysis. This implies that there is a pretty good chance that the selected option is NOT the best one.
Some examples...
"I've heard that the CPU spikes are caused by the garbage collector, so we need to reduce memory usage."
Geek-gossip...if you do not double check your sources you might work a lot to reduce the memory usage just to find out that the CPU spike has nothing to do with it.
"What!? You want to gzip everything that is going on the network! I know we need to reduce the latency, but this will use way too much CPU."
Educated guesses are brainstorming worst enemies. Why not try a quick prototype instead of killing the idea from the start?
"We absolutely need to redesign our web site using Ajax. Our user interface is clumsy."
Humm...sounds like techo-trend. Is the interface really clumsy? Why not initiate some usability tests to find out?
Guesses are good for estimates. Techno-trends are cool to discuss at lunch time. Geek-gossip is...gossip.
Brainstorming and facts are good for decision making.
Recently, I read "The McKinsey Way". The book is uneven; some sections are very interesting, some are close to useless. But I learned that when facing a problem, the best business consultants gather relevant facts first. Then brainstorm to find options. Evaluate, test, and finally, based on the results, select the best one.
This should apply to software development too.
Too often, decisions are taken without (real) fact checking, (real) brainstorming or (real) analysis. This implies that there is a pretty good chance that the selected option is NOT the best one.
Some examples...
"I've heard that the CPU spikes are caused by the garbage collector, so we need to reduce memory usage."
Geek-gossip...if you do not double check your sources you might work a lot to reduce the memory usage just to find out that the CPU spike has nothing to do with it.
"What!? You want to gzip everything that is going on the network! I know we need to reduce the latency, but this will use way too much CPU."
Educated guesses are brainstorming worst enemies. Why not try a quick prototype instead of killing the idea from the start?
"We absolutely need to redesign our web site using Ajax. Our user interface is clumsy."
Humm...sounds like techo-trend. Is the interface really clumsy? Why not initiate some usability tests to find out?
Guesses are good for estimates. Techno-trends are cool to discuss at lunch time. Geek-gossip is...gossip.
Brainstorming and facts are good for decision making.
Inscription à :
Messages (Atom)
