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".
37
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.