Human Factors and Web Engineering’s Intersection. Given my recent (and apparently insatiable appetite) for studying the contexts, interface(s), and success and failure modes between man and machine, it’s not a surprise that I’ve been flying head-on into the field of Human Factors. Sub-disciplines include Cognitive Engineering and Human-Computer Interaction (HCI). It would appear to me that there isn’t one facet of the field of web engineering that can’t be informed by the results of human factors research and ought to be part of anyone’s education in Operations at the very least. How we make decisions, how we operate under multiple goal conflicts (think time pressure and outage escalation), concerns for designing controls and displays, even organizational resilience has foundations in Human Factors, and I think has just as much to do with our field as Computer Science and Distributed Systems.
Preface, Human Factors for EngineersI am not a human factors expert. Nor can I even claim to be an able practitioner. Www.amazon.com/Unwritten-Laws-Engineering-Revised-Updated/dp/0791801624. How to be a Programmer: A Short, Comprehensive, and Personal Summary. Debugging is the cornerstone of being a programmer. The first meaning of the verb to debug is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind. Idealists that think design, or analysis, or complexity theory, or whatnot, are more fundamental are not working programmers. The working programmer does not live in an ideal world. Even if you are perfect, your are surrounded by and must interact with code written by major software companies, organizations like GNU, and your colleagues. Debugging is about the running of programs, not programs themselves. To get visibility into the execution of a program you must be able to execute the code and observe something about it.
The common ways of looking into the ‘innards’ of an executing program can be categorized as: Some beginners fear debugging when it requires modifying code. How to Debug by Splitting the Problem Space. (1) Jason Rubenstein's answer to What should you learn during your first job as a software engineer at a startup. (1) Jason Rubenstein's answer to What qualities make a good startup engineer.
If you call out bad code, make sure it's bad first - Naildrivin' ❺ So, someone shared some code on Github and some classic developer snark rolled in. And then there were some apologies about it. I saw those snarky tweets when they came through, clicked to the Github project, didn’t understand what the issue was, and went back to work. Now, I’m all for bad projects and bad code being called out. Our industry produces some shitty code, and a general lack of craftsmanship can kill business, or even people.
So bad code needs to be pointed out. No, it’s not. I think we can evaluate a project based on three criteria: should it exist at all? Should it exist at all? Replace is a command line app, which is something near to my heart. So, I’d say that it’s completely reasonable that this exists and wouldn’t be surprised if many people found it useful. Does it use the right technology? In Avdi Grimm’s take on this he writes: I totally agree with Avdi on this, but I don’t think it’s that relevant to the choice of technology here. Is the code itself well written? The Golden Rule of Programming | Stackify. There is one particular issue that seems to be the root of most bugs in software programs.
I see it over and over and over. Like most programmers, it has caused me heartburn since the day I started programming. So I have worked hard to make sure that my code never breaks my golden rule. I remind my development team every chance I get to also follow what I call the golden rule of programming. I think every new programmer needs a tatoo that says it. So what is the golden rule of programming? “If it can be null, it will be null” Null reference type errors are responsible for a good percentage of all application bugs. How about some simple examples of null values causing problems? Here is a classic example below. Public void DoSomething(string text) { if (text.ToUpper() == "Hello World") { //do something } } Some of the most common causes are settings, database calls, or API type calls not returning expected values.
Some tips to prevent null reference exceptions: Related Posts. What did the *really* successful programmers do differently. This is a follow-up to the lengthy "Do you want to be doing this at 50" discussion that we've been having here on HN for the past week. For those of you who might have missed it: As someone who is definitely on the path to be developing software for the rest of his life, I'm somewhat concerned.
I'm thinking of (contemporary) programmers of the caliber of John Carmack, Rich Hickey, Peter Norvig, Jeff Dean.. I think this is an interesting and valuable discussion for every developer out there. What Makes a Great Developer? What makes a truly great developer? Some might say a positive attitude. Some might say a high-sugar, high-caffeine, high-bacon diet. Some might say an absence of sunlight and as many monitors as a desk can support. I say pessimism and laziness are high up the list. What makes a truly great developer? Certainly, everyone has anecdotes about developers they've worked with who they thought were brilliant. Unfortunately, the best developers don't always come across positively.
Pessimistic Great developers are almost always pessimistic with regard to their work. They'll assume that at some point they'll need to undo work already completed, that hardware will fail, that all security will be compromised, and that your office will burn to the ground. By contrast, an optimistic developer will be more likely to simply assume code will work, or that it is secure, or give a deadline for a project without considering all the potential pitfalls. Lazy Likely to be heard saying: "We could automate that. " Hallmarks of a Great Developer - Test Guide. If you ask me, I'll tell you a great developer Plans before coding A great developer takes the time to plan an approach before designing or coding. A great developer knows that the time required to do so will be more than paid back by the time saved by getting it more right the first time. A great developer plans all scales of work, from envisioning multiple versions of a product to writing or modifying a small method.
Always knows why A great developer always knows exactly why they wrote a particular line of code, and why they wrote it the way they did. A great developer writes code because that code is the best choice for a particular situation, not just because it is the canonical implementation. Writes situation-appropriate code Any developer can write code. Deviates where and when necessary A great developer not only knows the canonical implementation but understands it is the canonical implementation.
Knows when not to change code Approaches debugging scientifically Groks the tools. Bad developer ≠ novice developer | Auto-Magical. My post on the nature of programming seems to have struck a nerve. Many commenters pondered what makes a developer great. “Ka” thought that: “You [are] not born [a] good or great programmer, you become one with time and study and hard work. At the beginning, everybody is a bad programmer.” I disagree. Let me give an illustration of what I mean from personal experience: When I got into Objective-C development, I was a “bad” developer.
After writing a lot of bad, buggy code, I drifted back to the comfort of .Net. Understanding anything complex requires the courage and integrity to engage in difficult, exhausting mental effort. There’s no happy ending to my story — yet. For more on the traits of great developers, read these posts by Dave Child and micahel.