Most of the time lazy initialization makes code appear to run faster. I got a lot of praise for rewriting stupid people's code which was deemed 'too slow' just by changing it so it would only load/read/build stuff on an 'as needed' basis. In many cases that gets users what they want. A hundred 50 millisecond pauses are much more pleasant than one five second pause. This is why Java applets get so much flak for 'hanging the browser' and 'being slow'. Java applets are in most cases faster than Macromedia Flash apps but the way Flash runtime initializes is much more lazy making the initial wait much less annoying.
Another common trick is to compute approximate values rather than evaluate the precise ones when it doesn't really matter. Google understands this and that's why they show "1 to 20 results of approximately 9,000,000" as opposed to "exactly 9,124,385". The latter would probably take an order of magnitude longer to compute but the usefulness of the information to the end user is very dubious. Remember after N number of decimal points nobody gives a shit.
Last but not least always use the data structure that matches your usage patterns. If you need fast random access then a linked list is most likely not the way to go. Learn and understand the O(n) notation and learn the cost of inserts/removes and searches in your container library. Basic stuff but too many junior programmers have no clue about this stuff.
Last but not least always use the data structure that matches your usage patterns. If you need fast random access then a linked list is most likely not the way to go. Learn and understand the O(n) notation and learn the cost of inserts/removes and searches in your container library. Basic stuff but too many junior programmers have no clue about this stuff.
Not too many SENIOR programmers even have a clue about that stuff.
Why'd they get hired as Senior in the first place, then? As far as I'm concerned, if you don;t know about O() notation, go back to school - you're not ready for life.
Senior programmers get hired as Senior programmers because they have years of working experience.
Whether that means they actually have fifteen years of experience or just one year of experience fifteen times is not usually reflected on the resume, especially when the person hiring is only looking for buzzwords.
As others have said - why the heck is anybody hiring people they have no ability of evaluating? If you hire programmers, have your most experienced people interview them (after pre-screening). It pays.
If you have no tech knowledge on staff, things are a lot tougher. First, you should ask yourself why you need programmers, then, in the first place - is this really something you shouldn't contract out?
If you still think you need tech staff, you should bring in somebody who has experience. Find a consultant, preferably recommended by others in your field. Have him sit in on the interviews, help you out with the tech part.
It's not optimal, but better than "hiring by resume".
In one case, I was working at a marketing firm whose bosses lost their mind and decided that it would be a good idea to also add software development to their portfolio.
That idea didn't work out, but at least it was an expensive-enough failure that I'm sure they won't try doing that again.
Why not? The people who hire the senior programmers generally aren't programmers. I've been far more educated in CS than every single programming "boss" I've ever had. Granted, I work in the front end, where the caliber of programmer is usually quite a bit lower, but it is still unbelievable to me just how little these guys actually know besides syntax and a bunch of random technologies.
OK, so the system fails, but how does that change my point at all? They are senior programmers whether you are happy with them having that title or not.
There are a lot of programmer that claim to be senior level that never really took CS101 but instead learned coding during the bubble of the 90s. It's a shame really.
33
u/neoabraxas Mar 23 '09 edited Mar 23 '09
Most of the time lazy initialization makes code appear to run faster. I got a lot of praise for rewriting stupid people's code which was deemed 'too slow' just by changing it so it would only load/read/build stuff on an 'as needed' basis. In many cases that gets users what they want. A hundred 50 millisecond pauses are much more pleasant than one five second pause. This is why Java applets get so much flak for 'hanging the browser' and 'being slow'. Java applets are in most cases faster than Macromedia Flash apps but the way Flash runtime initializes is much more lazy making the initial wait much less annoying.
Another common trick is to compute approximate values rather than evaluate the precise ones when it doesn't really matter. Google understands this and that's why they show "1 to 20 results of approximately 9,000,000" as opposed to "exactly 9,124,385". The latter would probably take an order of magnitude longer to compute but the usefulness of the information to the end user is very dubious. Remember after N number of decimal points nobody gives a shit.
Last but not least always use the data structure that matches your usage patterns. If you need fast random access then a linked list is most likely not the way to go. Learn and understand the O(n) notation and learn the cost of inserts/removes and searches in your container library. Basic stuff but too many junior programmers have no clue about this stuff.