Everyday Problem Solvers
As the 1940’s air war in Europe intensified, the Allies faced a major problem. Their bombers would leave England by the hundreds, but too many of them didn’t return, brought down by extremely heavy enemy flak. The Allies desperately needed to beef up the armor on their planes to provide protection, but armoring an entire plane, or even an entire cockpit, involved far too much weight. How could they choose the few especially vulnerable places to be armored?
A couple of clever engineers solved this problem with a counter-intuitive analysis. After comprehensively logging the locations of flak damage inflicted around the fuselages, engines, and cockpits of planes returning from hundreds of bombing runs, they calculated Read more of this post
As you know (or not) I’m Brazilian. I was born in Brazil, studied in Brazil, I work in Brazil, and (I’m ashamed to say) never been to a English speaking country. Nevertheless my blog is written in English and more often than not I hear the question “Why English? Why not Portuguese?” and I my answer always is “Because I want to reach as many people as possible”. Reaching people is not why I write this blog (my motives are strictly selfish) but it’s the motive why I do it in English.
I also program in English. When people ask me why I reply: Read more of this post
kmote asks: I am newly employed as the sole “SW Engineer” in a fairly small shop of scientists who have spent the last 10-20 years cobbling together a vast code base. (It was written in a virtually obsolete language: G2—think Pascal with graphics). The program itself is a physical model of a complex chemical processing plant; the team that wrote it has incredibly deep domain knowledge but little or no formal training in programming fundamentals. They’ve recently learned some hard lessons about the consequences of nonexistent configuration management. Their maintenance efforts are also greatly hampered by the vast accumulation of undocumented “sludge” in the code itself. I will spare you the “politics” of the situation (there’s always politics!), but suffice it to say, there is not a consensus of opinion about what is needed for the path ahead. Read more of this post
Last sunday I watched The Avengers (awesome movie by-the-way, Kudos to everyone involved) and yes The Hulk is awesome, Scarlett Johansson is hot and Thor does have a mighty hammer, yes, but my favorite character is not a human, it’s a software, and it’s know by “Jarvis”. In fact what I like most about Iron Man movies is not the plot, or characters or Robert Downey Jr. What I like most is the tech, specifically Jarvis. Read more of this post
I will not lie: I always had a beef with literature and non technical text interpretation. Dont get me wrong: I’ve never misunderstood a math problem text, or a chemestry-phisycs one, but when the literature teacher would say that the poem was about the solitude and the seek of self I was always like “WTF?!? where did she took that from?!? this poem is about a man who enjoys long walks in the desert!!!”. Some say that I might be a little too literal and stuff, and I disagree! I’m practical, rational, precise, objective and I belive that if you want to tell the world about “solitude and seek of self” you should do it clearly and precisely, and not by writing a 200 foot long poem that tells the story about a man walking in a desert.
And yet no one expect to find something like this on poems:
Roses are red
Violets are blue
// Here I’ll define the meaning of life
I don’t live for myself
// And now a recursive definition of life
I live for you
I know, very Shakespeare-like… The point is: Why should a programmer write comments on his own code?!? If something was very hard to figure out and program, it should be very hard to understand and maintain! Right?!?
First of all I’m sorry I’ve been so absent. I’m working on something of my own and I hope I can make it stable and working properly so I can talk about it here.
Meanwhile I read a nice post and I’m reposting it here:
In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. They devised a form that each engineer was required to submit every Friday, which included a field for the number of lines of code that were written that week.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw’s region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
I’m not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.
As most of you already know, there’s a buzz about who should learn to program and who should not. I will say now that im in favor that everyone should, and I say this because as you learn to program you learn a set of techniques that will most definitely help you all of your life.
Most people who are discussing this matter are focusing on the question “Ok, I learned to program, now what do I do with it?”. My answer to this question is: “I don’t care!”. Read more of this post
According to Wikipedia maturity is:
a psychological term used to indicate how a person responds to the circumstances or environment in an appropriate manner. This response is generally learned rather than instinctive, and is not determined by one’s age.
It is a widely know and accepted fact that write logs is a very good thing, since it helps you find out what happened at a given moment of time. It is rule number one on the universal developer book, if it existed… But again and again I find a lot of programs that just don’t do it.
I’m used to clients calling and say that something is not correct with the product, but it makes me cry when I ask for the logs and he says that there are none and I want to kill the dev who didn’t write log. I always find the bastard. If by any chance it is not a intern, oh help me lord, some blood will be shed!
Logging came to me as a very instinctive thing. My firsts programs didn’t write any log, but of course, I was the only one using them. But as I got better and better i felt the need to better control my “world”. I was scared of the fact that a problem would occur and I wouldn’t be able to know about it. In order to really evolve and grow as developer one needs to make more complex and bigger programs and, more importantly, learn from ones own mistakes. Logging is perfect for the learning part, because you don’t need to bother the users with questions and other stuff (if you logged all the information you needed).
One might start to wonder what does it have to do with maturity. Just logging is not enough. Logging for the sake of it does not help. You need to have a consistent, useful, categorized and, most of all (I think), easy to track log message. It takes real-maturity to know how to log. You should log everything that happens but each event must be logged in a particular way. Logging user interactions that same way you log Null Reference Exceptions is not very helpful. Remember that logging provides information and information is gold!
A lot of people do write a bunch of logs. They actually log the entire thing. Take World of Warcraft for example: Everything you do in the entire game can be traced! They can trace every little critter that you killed. They know which weapon you used. They log everything! But, as i said before, just write messages is not enough. You have to write them in a understandable, easy-to-track way. If a developer in your team can’t trace back, for example, the users actions, such as buttons clicked, radio button choices, in-screen info, check-boxes selected, etc, your log is not good. It might help you find and solve a problem, but it could do a lot better. I recently learned a important lesson.
I must say that I have never had a problem with production environment software (Yes, my programs bugs, but always very soon after deploy, so I was always very close by to help). Thank god all programs that I wrote never gave me serious headaches. Until a couple weeks back. Deploy went fine and everything was peachy. So one beautiful morning the client called me and reported a issue. As always I asked for the logs, he sent me and then the my world felt apart. I could not trace what was going on. Everything was there, but i could not set a time-line to the events. Due to multiple front-ends and multiple web services servers it was very, VERY hard to track what happened to a user. I had a special hard time figuring out what messages on the web services logs belonged to whom. It was a nightmare. I wanted to cry. But I managed to do it and I matured a bit… no, I matured a byte… sorry for the pun…
So now I’m developing a new logging lib and a log-reader tool (feel free to “borrow”) that is planned to solve the multi user/thread/server scenarios. The current log lib we use today is perfect to developer and single-user/thread/server scenarios. You can easily “follow” up what and when it happened, what came after what and so on. But when multi-thread/multi-users/async-operations come-out to play things get ugly. Since the current lib only logs the time and severity of the event its very hard to track continuous actions of a user, or even the path of a particular thread.
The lib itself is not enough though. The real magic is the log reader. The reader creates a visual path of the massages. It literally creates a “fork” for multithread visually showing parallel operations and stuff! Its getting very cool when its ready ill post the source code… but now back to maturity…
I must disclose that I’m not the most seasoned developer out there… for christ sake I’m only 24, but this much I can say: Write easy to read and understand log messages. Your kids will be thankful! Ok maybe not, but you will when you need to know whats really going on!
I know that the internet is full of posts about this, and trust me, I’ve read a bunch of them, and noticed that they’re all basically the same. They all focus on how and what to put on the slides, they compare PPT and Keynote and ultimately try to teach how crowd concentration works and how to retain your audience attention.
The fact is that having perfectly built slides, beautiful pictures, nice videos and demos does not guarantee a killer presentation. A killer presentation is a presentation where you expose whatever you want to expose knowing that the viewer is listening to that info, and that he will remember that info and pass/work it around.
The first and most important topic on how to make a killer presentation is to KNOW whatever you’re talking about. Ask yourself: Can I explain what im trying to say to a 6-year-old? If the answer is no, then you don’t know it yourself. Einstein said that. Steve Jobs is widely known as a presentation master and he also shared this notion. PPT/Keynote were banned from internal meetings, if you presented something using a PPT instead of a whiteboard you would be interrupted and deemed incompetent. Steve only used slides for public presentations. He also was a firm believer that if you know something you don’t need slides to explain it!
The second item in our list is “Be Confident”. Second guessing yourself on stage is a fatal mistake. When you enter the stage you have 70% of the crowd “trust”. This means that they trust you but there’s a silent voice on their heads telling them that things are never as good as they sound. If you’re confident and show that you do know what you’re talking about they won’t question. If you second guess yourself the little voice start to get stronger and eventually it will take over and you will be talking to empty-full room.
The third order of the day is “Be In Love”. Being confident don’t get the other 30% of the crowd’s attention. Showing passion for the topic on the stage does. When you show that you really care about whatever you’re presenting, that you worked your “but-off” to be there and tell them whatever is your saying, the crowd subconscious will notice “the love in the air” and will silent the inner voice.
The fourth tip is very simple but very often overlooked: “You are presenting, not the slides”. In a presentation the slides are not the focusing point. The presenter IS! Slides are helpful but you, the presenter, is the core of the presentation. Doesnt matter if you’re presenting a new Presentation platform. Slides are “support material”. Steve was a master in this point: His slides were always very basic, most times they had only one number, or maybe three words or even only a photo. The focus was always on Steve.
The dessert is: “Don’t fall in love for your own voice”. When preparing the presentation ask yourself: “What if I don’t talk about X?”. Always question the “weight” of your presentation. I usually say that if your slide has more than 10 words a lot can be shrunk. Think clean, think efficiency!
In classical computer science the Real Programmer (a.k.a Hardcore Programmer) is a mythical man who writes code almost in bare metal. The most high level language he uses is ANSI – C and he debug code in hexadecimal and things like that…
I don’t know anyone that fits that description but investigating and (mostly) philosophizing I came up with a real-world definition for the Real Programmer:
Think I forgot something? Please fell free to comment!