|
I'm going to avoid casting aspersions on my fellow developers and instead simply own up to my own failings… I've been developing software since I was 10 years old (my first program was written in BASIC on a Commodore PET), and professionally for well over a decade, and for most of that time, I believed that design was someone else's job, and that it didn't matter whether I could design my way out of a paper bag. WRONG! Design is everyone's responsibility, at least to some degree.
|
|
|
|
|
Quick glance through the article I am concerned that Microsoft's left hand does not know what the right hand is doing (Prism vs. Metro). Windows team is again going in a direction that it deams best (for whatever reason). I consider Windows team to be a disaster. I would be more worried about creating a clean implementation that is flexible for many environments, including using multiple proecessors effeciently. I have the feeling that there is too much code in Windows that is not clean. The front end should be flexible, just like the ability to put different front ends on WPF.
|
|
|
|
|
I think everyone should learn how to think and when to dig deeper and should be able to do it in a welcoming and friendly environment. Learn how to question how things work. Learn that everything new and simple hides something large and complex. We are all standing on the shoulders of giants like Newton, Tesla, Kettering, Berners-Lee, and on and on. It's all magic until you learn how it works.
|
|
|
|
|
I’ve seen a few people, over the years, compare knitting to programming. It usually goes something like this: Wow, have you ever looked at a knitting pattern? It looks kind of like source code! Those knitters must be real geeks! Is what you’re doing programming? Of course not! It’s the reverse of programming: you’re reading a series of low-level instructions and doing what they say. It would be more accurate to say you’re an interpreter, or possibly a compiler. Pearls of wisdom on purl and Perl.
|
|
|
|
|
It's been recently brought to my attention that I don't view open-source the way that many of my friends do. My attitude has always been: Here's some code that works well for what I want. If it works well for what you want, great! I might be a bad open-source citizen.
|
|
|
|
|
To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds. Everything you always wanted to know about programming but were afraid to ask.
|
|
|
|
|
I've seen the future and it is iOS. Apple is moving solidly and confidently towards consumer computing and away from mollycoddling the power users. The company knows where its profits come from and power users ain't it. The iPad -- with its simple interface, strong security, and dependability -- has set the standard for what's next. No more system-wide hotkeys for App Store apps. What a shame...
|
|
|
|
|
If Apple changes to a 4-inch screen in the next iPhone (iPhone 5,1), how could they do it while minimizing impact on users and developers? Assuming everyone wants a bigger screen, how does Apple implement it without breaking existing applications, causing backwards compatibility problems, and otherwise fragmenting the platform and frustrating stakeholders? Let's try to figure that out. It takes a little more than pinch-to-zoom.
|
|
|
|
|
To accurately emulate the humble 3.58 MHz Super Nintendo on a PC, we need computers running about one thousand times faster than the little grey console's humble CPU. Perfection, it turns out, comes at a high price. But the payoff, at least in one man's eyes, is the preservation of an important piece of video game history. Life is a game, kid! It all depends on how you play!
|
|
|
|
|
You might find this hard to believe: not everyone owns an iPhone or one of the several thousand decent Androids for sale or even a Windows phone. Crazy! But what's even more insane is the number of shockingly horrible dumbphones major US carriers are still selling like it's 2006. Here are the worst of the worst. Operators are standing by...
|
|
|
|
|
I would like to see a shift in consumer electronics back to a model in which gadgets are designed to be repaired and consumers are encouraged to replace or upgrade every ten years or more, not every year. What I'm suggesting is of course exactly the opposite of what's happening now. Remember when soldering was a common DIY skill?
|
|
|
|
|
Can't use DIY tools to remove the tiny components (surface-mount chips)they have on a cellphone or iPod.
|
|
|
|
|
In this installment we talk to Jesse Liberty, a well-known developer, author, instructor, podcaster and currently a Developer Evangelist for Telerik. We talk to developers about their backgrounds, projects, interests and pet peeves.
|
|
|
|
|
Awesome interview Jesse. I enjoy your writing and thank you for helping keep it interesting.
Good luck in future. Will we see a Windows 8 book in future? 
|
|
|
|
|
It turns out you don’t have to be employed as a programmer to use programming at your job. Necessity is the mother of invention.
|
|
|
|
|
Quote: I spent the next four days surfing the web
Unless he was on Code Project, I don't think he's cut out to be a real programmer.
Terrence Dorsey wrote: Necessity is the mother of invention
And the father is Tesla.
|
|
|
|
|
Did he just realize that? 
|
|
|
|
|
"When I was a college student, I spent a few summers working at a law office as a file clerk. Basically, the job was as boring as it sounds: get requests for files from the file room, physically sort through boxes, pull out said files, deliver them. Occasionally rearrange the entire file room to accommodate more boxes."
Even before programming, the guy was the file server for the firm!
Rearranging the file room? That sounds like a database reload.
|
|
|
|
|
My goal for Johnny-Five is to create a framework for programming Arduino Robots with nothing more then JavaScript. I believe that JavaScript, inherently asynchronous and the platform that Node.js has built around this paradigm, is the perfect environment for writing evented, streaming programs for controlling the highly synchronous world of hardware. The 4th rule of robots: program them in the language you like best.
|
|
|
|
|
NO NO NO NO, this is the stuff of nightmares!
|
|
|
|
|
Many people don’t expect pairing, itself, to be a skill. They don’t realize that they’re going to have to learn new ways to think, to problem solve, to be creative, to filter their perceptions, and even to converse. Since they don’t realize this, they get surprised. And then they set themselves up to make that learning hard, and quit when they get poor results and find pairing to be hard while learning. It takes two to tangle.
|
|
|
|
|
I've never really used it beyond a couple projects at school, but I hate pair programming. Mostly because I hate having someone looking over my shoulder. Only in the physical sense though, something about having someone looking over my should just makes me freeze up. If what I typed was duplicated to another monitor somewhere not directly behind me, or something to that effect, I'd be fine it.
|
|
|
|
|
It sounds ridiculous. I've never done and I don't expect I ever will.
Frequent code reviews make more sense.
|
|
|
|
|
it really suits me. My creative reasoning really comes alive when I'm involved in a conversation. Compared to solo work, working in a pair lets me do like 80% of the feature count in the same elapsed time, with 1/50 the bug count.
|
|
|
|
|
I suppose I'd have to give it a longer try. Recently, I spent most of a day trying to figure out something with a coworker. Then I spent an hour after work and I'm pretty sure I got it solved. Though, that may just be because I had enough preparation with the coworker that I had everything I needed to finish solving the problem. I'm not sure.
One thing I did notice though was that we each learned a few things. He learned some ways of doing things in LINQ and how to better use Umbraco (a CMS we use), and I learned a few things about our infrastructure at work (and how frustrating parts of it are).
Another thing I noticed is that I was mentally exhausted at the end of the day. I went home, fell asleep immediately, and woke up 9 hours later (which happened to be 4AM)... that never happens to me (if I go to sleep early, I usually wake up in a couple hours). I think the experience basically kept me mentally engaged all day, which is why I was so tired.
One downside I saw was that, when sitting next to somebody, you don't really have the opportunity to stare into space for a few minutes considering the problem. It'd probably be good to take breaks on occassion, if only to think to oneself.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
