Home
Joel Liu's Library tagged → View Popular, Search in Google
-
Wouldn't you expect a truck driver with twenty years of driving experience to perform better than a rookie with less than a year of road time under his belt? Of course you would. And shouldn't a grizzled ten year veteran of dozens of software projects-- like, say, myself-- perform better than some punk kid directly out of college? Well, you might think so, but in the bizarro world of software development, that logic doesn't apply:
-
Building something doesn't teach you much about quality if you don't have someone to review/assist every now and then.
-
This year, Facebook and the National Security Agency were sponsors — and both are using the event for recruiting purposes.
The best of the best was 18-year-old Bin Jin, a high school student from Shanghai, who swept the algorithm competition and beat contestants with doctoral degrees, as well as Petr Mitrichev, a Moscow State University student and three-time world algorithm champion.
in list: Unserstanding developers
-
3. Don't play any blame games. It doesn't matter who put the bug in. Again, your co-workers will be more loyal to you if you soft-pedal problems they introduce. I often apologize for bugs found, and gently argue with people that it was indeed my fault, when we both know it wasn't.
-
If you don't know who Corrinne Yu is or what she has done, you are in for a special treat. Corrinne Yu is Principal Programmer at Microsoft's Halo team, and first party Halo Lead. She is the first and only female Technical Lead of the whole Microsoft Game Studios. She has worked as Director of Technology of several 3D game companies. She is the first female founding member of Microsoft's Direct 3D Advisory Board and Graphics Advisory Board. Besides gaming, she had programmed on the Space Shuttle Project at Rockwell International California. She had designed and conducted accelerator experiments at LINAC in California and the accelerator at Brookhaven National Laboratory. Her nuclear physics research had won her a national award from the U.S. Department of Energy. She volunteered time in the past to advise on CUDA, visual computer and GPU simulation at NVidia. She remains active on the GAB and continues to volunteer time to review the designs of new Direct 3Ds. Check out this interview with Corrinne Yu, Halo Team Principal Programmer.
in list: Unserstanding developers
-
Let's say that this follows the 80-20 rule. Roughly 80% of programmers don't read books, don't go to conferences, don't continue learning, don't do anything but what they covered in college. Maybe they've gotten a job in a big company where they can do the same thing over and over. The other 20% struggle with their profession: they read, try to learn things, listen to podcasts, go to user group meetings and sometimes a conference. 80% of this 20% are not very successful yet; they're still beginning, still trying. The other 20% of this 20% -- that's about 5% of the whole who are 20x more productive.
-
These people are not those who can remember all the moves and have fingers that fly over the keyboard erupting system commands. In my experience those in the 5% must struggle to get there, and struggle to stay there, and it's the process of continuous learning that makes the difference.
- 5 more annotation(s)...
-
Writing is also hard, and you’ll find plenty of instances where the authors come up short. The burden is on you to prove beyond a shadow of a doubt that you’re right and the author is wrong. If you’re not bending over backwards to try to say “well, maybe the author was using it in the context of..”, you’re not giving them much credit, and might not be putting enough thought into the process. When you find yourself saying “this code is awful!”, try thinking of how you would do it yourself. Sometimes you find that you come up with a better way than the author. Sometimes you’re led right back to the same solution as the author.
-
This is where a programmer’s critical thinking skills will shine.
Granted, it’s difficult to determine the ramifications of question such as, “What would the impact of using this non-standard syntax be if I made 300,000 library users adopt it?”. However, thinking on such a big scale can only help you as a programmer, and the bigger you think, the more you help yourself.
- 1 more annotation(s)...
-
The process of designing before coding is becoming outdated. Documenting designs is becoming even rarer. Many developers have never written a design document and cringe at the idea of doing so. Many who are required to, typically generate a lot of interaction diagrams and class diagrams, which don’t often express the developer’s thought process during the design phase. This article will discuss how to do write an effective design document concisely with no special tools, and without needing to know UML. It will also discuss why a well written design document is one of the most valuable tools a developer can have when entering a new project.
-
The term "programmer" has historically referred to a menial, manual input task conducted by an unskilled worker. Predecessors of the computer, such as the Hollerith machine, would be fed encoded instructions by operators called "programmers". Early electro-mechanical, valve and relay-based computers were huge and expensive machines, operated within an institutional environment whose hierarchical division of labor involved, at the lowest level, a "button pusher" whose task was to laboriously program the device according to instructions developed by those higher up the technical ladder. So the programmer role is traditionally concerned only with the input of data in machine-compatible form, and not with the relevance or adequacy of those instructions when executed.
-
Developers view the business domain as their "second job." They work to develop a solid understanding of those aspects of it that impact upon their software, then use that knowledge to determine what the real business problems are that the application is meant to be solving. They make an effort get inside the heads of their user base - to see the software as the users will see it. This perspective enables them to anticipate requirements that may not have occurred to the users, and to discover opportunities to add business value that the users may have been unaware was technically possible.
- 2 more annotation(s)...
Selected Tags
Related Tags
Top Contributors
Groups interested in Programmer
Diigo is about better ways to research, share and collaborate on information. Learn more »
Join Diigo