Showing posts with label evdevshokno. Show all posts
Showing posts with label evdevshokno. Show all posts

Tuesday, February 23, 2010

Monday, January 04, 2010

Thursday, May 28, 2009

Every Developer Should Know ... no more

I had this grand idea for blogging. I'd blog about all those things that it amazes me that other developers don't know.  The things that I thought every developer should know, but, it seems so many don't.

In amongst some other grander ideas it was also intended to encourage me to blog more and more frequently.

Unfortunately having 'another blog' didn't motivated me to blog more frequently, it just became an extra pressure.  It therefore seemed an excellent candidate for things to face the cut when I decided to rationalise what I spend my time on.

Until the domain expires it will point here and the original posts are at http://everydeveloper.blogspot.com/

I've also imported most of the posts into this blog (http://blog.mrlacey.co.uk/search/label/evdevshokno). Hopefully I finish some of the draft posts too. - Perhaps.

Monday, November 24, 2008

Monday, September 29, 2008

EDSK ... being a developer is not the same as being a designer

Every developer should know that being a developer is not the same as being a designer.

Just because you can program the server side of a website doesn't mean that you are the best person to design the graphics, layout, colour scheme or logos.

Just because you are an expert at optimising data retrieval from relational databases doesn't mean that you should be designing the layout of the forms used to display that data.

Or, if you're a design whizz, it doesn't mean that you should be writing the code of an application that uses your designs.


 Why is this important?

Be honest with yourself. Know your limits.  Focus on what you are best at. Let the people who are best at different tasks work on those tasks.
I know I'm not a great designer. Just look at this site. (One day I'll get a designer to make it better.)
I'm not saying you can't be both, just that most people aren't.




What do you do once you know this?


Don't be afraid to defer a task to someone better skilled.
It'll allow you more time to focus on what you're best at.
Would you rather be the developer of some amazing software that someone else designed? Or the developer and designer of some software that is only OK?

Friday, September 26, 2008

EDSK: Some unofficial research

I sometimes feel like I never post on EveryDeveloperShouldKnow.com. In reality I know I've got over 100 drafts that I've yet to finish. Why do I find finishing writing so hard?

Anyway, before I force myself to finish what I've started, I thought it was worth checking that other people agreed with my assumptions on what I thought was important.

I decided to do a bit of research and see what other people thought that other developers should know.
I only hope that the post I put on stackoverflow doesn't come more comprehensive than what I put on my site.

Tuesday, September 23, 2008

Saturday, September 13, 2008

Wednesday, July 30, 2008

Friday, June 20, 2008

Tuesday, June 03, 2008

Tuesday, May 27, 2008

Sunday, May 18, 2008

EDSK ... that they must be involved in implementation

"The designer of a new kind of system must participate fully in the implementation."
"… the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. … If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important."

Friday, April 25, 2008

EDSK ... you won't get rid of all bugs, add all the features or write all the programs

Every developer should know that you won't get rid of all bugs, add all the features or write all the programs you might want to.


Why is this important?

You need to set limits and prioritise.

There isn't enough time to do everything. So you need to focus on what's important and do that!


There isnt' the time to fix every bug. So fix the ones that cause the biggest problems or affect the most people (or whatever criteria you use to prioritse bugs) first.  By the time you've made those changes, circumstances may be different.

Make sure you're adding the feature which will bring the most benefit.  Not just the one that is easiest to code, or most fun.

Make sure you're creating a new program that is of use, doesn't already exist and will actually benefit others.
 


What do you do once you know this?
Prioritise!
Make sure you're doing something that is worth doing.
Don't do one thing if there's another that is more important.
Understand the costs and benefits of fixing the bug, adding the feature or creating a new program, before you write the code.

rethinking EDSK

I think it's a suitably big understatement to admit that I'm not meeting my posting deadline on Every Developer Should Know.... In an attempt to address this and help me fit in a bunch of other stuff I'm trying to do, a bit of a restructure and reprioritisation is in order.
From an EDSK point of view I'm gonna start thinking more short term. I had long term plans to extend beyond tips that are generic to all developers and also include content more targeted to developers using specific technologies or targeting specific environments/platforms.
I had starting collecting references to relevant pieces on the web, but to help me focus on what I'm working on right now I'd stop. I also thought I'd post up the link so they don't go to waste.

Linux Developers should know:
Ten Commands Every Linux Developer Should Know

.NET Developers should know:
What Great .NET Developers Ought To Know
MSDN Webcast: What Every Developer Should Know About the .NET Framework, But May Have Missed Along the Way (Session 5) - Level 200
What Every Developer Should Know About the .NET Framework, but May Have Missed Along the Way
Visual Studio Add-Ins Every Developer Should Download Now
Ten Must-Have Tools Every Developer Should Download Now
.NET Framework General Reference - Design Guidelines for Class Library Developers
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries
Database Developers should know:
... about normalisation. Not just how to do it but why.

Java Developer should know:
Ten Things Every Java Developer Should Know About Unix
Best Java book available
I've been using Java since 1995 and have owned this book since 2001 and it's the only Java text I still turn to. I recommend every Java developer, no matter what level you're at, read this book and read it again every year for the remainder of your career.

Ten Things Every Java Developer Should Know About Unix

PHP Developers should know:
10 Tips That Every PHP Newbie Should Know
10 Tips That Every PHP Developer Should Know, Part 2
make life as a PHP developer a whole lot easier

Web Developers should know:
8 Firefox Add-ons every Web Developer should know about!
Speed up your web pages with YSlow
Color Oracle takes the guesswork out of designing for color blindness by showing you in real time what people with common color vision impairments will see.
Advanced JavaScript Debugging Techniques
What Every Web Developer Should Know
... the differences between REST and SOAP.

Windows Developers should know:
... to avoid using the clipboard programmatically
Eight resources every developer should know about
... about COM
... about User Account Control (UAC)

Thursday, April 10, 2008