50 characteristics of a great software developer

1. Passionate; loves computers and programming, takes an interest and thinks about things even outside working hours.
2. Curious; wants to understand new things, researches unfamiliar terms.
3. Humble; recognizes that other people are smart and have great ideas and knowledge, respects relationships more than technology.
4. Creative; sees ways to do things that others don’t see, comes up with better ways of doing things, goes beyond.
5. Friendly; easy to get along with, does not sabotage or bring down team morale.
6. Fast learner; can quickly research, understand and use unfamiliar software technologies, tools and languages.
7. Focus; works towards completion of tasks with minimal distraction, avoids taking tangents.
8. Comprehension; can make sense of software requirements and understand what it is that needs to be built, able to grasp the “mental model” of the internal structure of a software application.
9. Logic skills; ability to devise logical solutions for programming problems.
10. Pragmatic; able to make a value judgement about what is really important, values practical outcomes and getting the job done, avoids gold plating.
11. Not dogmatic; willing to change their mind and see things from the perspective of someone else, values the intellect of others. Not a jerk.
12. Workman like; willing to do the drudge work as well as the exciting work.
13. Thorough; puts in the 10% more needed to do a great job rather than an adequate job.
14. Intellect; able to grasp very complex computing concepts, able to develop very sophisticated code, able to do “the hard stuff”.
15. Energy; productive, motivated, strong work ethic, gets a lot of work done in the available working time.
16. Practices; writes lots of code, especially in the early years.
17. Persistence; sticks at it, takes the time needed to get something done or to learn something new.
18. Flexible; adaptable, happy to take new directions, happy to work with new technologies, happy to try new things, happy to change priorities.
19. Thirst for knowledge; actively self educates, reads and researches, willing to learn from others, always believes there is always much more to learn.
20. Expert knowledge; has superb knowledge of, and has thoroughly researched the primary programming languages (typically 3 or fewer), object models and frameworks that they do most of their day to day programming with.
21. Deep knowledge; has an in-depth understanding and experience in some small number (typically fewer than 10) programming languages and related technologies.
22. Broad knowledge; has passing familiarity with a very wide range of programming languages and related computer technologies.
23. Ability to write; can string words together to communicate. Client emails, co-worker emails, documentation, emails, proposals, blog posts, tweets.
24. Knowledge of computer science fundamentals; object oriented programming, design patterns, algorithms and data structures, how computers work at a low level, hardware, operating systems, networking, databases & much more stuff.
25. Verbal communication; able to explain their own thought process, can explain complex concepts, can participate in discussions with team members, can communicate with customers/users and other non technical people.
26. User oriented; can empathise with users, understands where the users are coming from and what is most important to them.
27. Software design and architecture; can design class structures, can design API’s, can design subsystems within an application, or can design entire application architectures.
28. Quality oriented; understands software testing, writes tests for their code where appropriate, understands the concept of test driven development, meets organisational expectations for testing & quality, feels satisfied by a job well done.
29. Balances coding priorities; knows when code should be written primarily for robustness, maintainability, reusability, speed of development, execution performance, scalability, security, polish, presentation, usability or some other factor.
30. Problem solving; knows how to attack a problem and has the tenacity to solve even very hard problems, uses appropriate debugging tools.
31. Development tools; understands their development tools, compiler/IDE and knows how to get the most out of them.
32. Seeks simplicity; understands the danger in complexity, prefers simple solutions.
33. Interested in the field; Knowledge of the industry, trends, directions, history.
34. Avoids re-inventing the wheel; able to look at a problem, analyse it, work out what class of problems it comes from, can find patterns, libraries, algorithms, data structures or other pre-existing solutions that might fit the problem well and reduce the need to write code.
35. Honest; can admit mistakes, unafraid to admit they don’t know something.
36. Detail oriented; pays close attention. Avoids missing things, not sloppy or half-baked.
37. Understands the lifecycle of software development; the roles played by developers and other people in that process.
38. Manages own workload; able to prioritise their own tasks, willing to adapt to change.
39. Cares about maintainability.
40. Uses source control.
41. Appreciates peer review; does not feel threatened or insulted by peer feedback.
42. Groks; is able to read source code and learn what it is doing.
43. Understands performance; able to optimise and write fast code when appropriate, knows how to avoid common performance problems.
44. Writes clean code; readable, well formatted, appropriately commented code.
45. Understands requirements specifications; able to make sense of software requirements, knows how to resolve questions and ambiguities, understands the relationship between requirements and testing.
46. Follows coding standards; where there is such an expectation.
47. Wants to be working on this project, at this company; a programmer is unlikely to do a great job if they are working on a project they don’t enjoy, or working at a company they don’t like.
48. Strong research skills; good at ferreting out information: digging through documentation, searching the web, reading reference guides, release notes, discussion forums, mailing lists. Knows how to find answers.
49. This slot reserved for suggestions - anything I’ve missed?
50. Goto 49.

Parallel Programming

Parallel Programming in the .NET Framework

.NET Framework 4

Other Versions 

Many personal computers and workstations have two or four cores (that is, CPUs) that enable multiple threads to be executed simultaneously. Computers in the near future are expected to have significantly more cores. To take advantage of the hardware of today and tomorrow, you can parallelize your code to distribute work across multiple processors. In the past, parallelization required low-level manipulation of threads and locks. Visual Studio 2010 and the .NET Framework 4 enhance support for parallel programming by providing a new runtime, new class library types, and new diagnostic tools. These features simplify parallel development so that you can write efficient, fine-grained, and scalable parallel code in a natural idiom without having to work directly with threads or the thread pool. The following illustration provides a high-level overview of the parallel programming architecture in the .NET Framework 4.

For More Details Visit: http://msdn.microsoft.com/en-us/library/dd460693.aspx

Accessing Attributes With Reflection

 

The fact that you can define custom attributes and place them in your source code would be of little value without some way of retrieving that information and acting on it. C# has a reflection system that allows you to retrieve the information that was defined with custom attributes. The key method is GetCustomAttributes, which returns an array of objects that are the run-time equivalents of the source code attributes. This method has several overloaded versions. For more information, see Attribute.

An attribute specification such as:

C#

[Author("H. Ackerman", version = 1.1)]
class SampleClass

is conceptually equivalent to this:

C#

Author anonymousAuthorObject = new Author("H. Ackerman");
anonymousAuthorObject.version = 1.1;

However, the code is not executed until SampleClass is queried for attributes. Calling GetCustomAttributes on SampleClass causes an Author object to be constructed and initialized as above. If the class has other attributes, other attribute objects are constructed similarly. GetCustomAttributes then returns the Author object and any other attribute objects in an array. You can then iterate over this array, determine what attributes were applied based on the type of each array element, and extract information from the attribute objects.

Example

---

Here is a complete example. A custom attribute is defined, applied to several entities, and retrieved via reflection.

C#

[System.AttributeUsage(System.AttributeTargets.Class |
                       System.AttributeTargets.Struct,
                       AllowMultiple = true)  // multiuse attribute
]
public class Author : System.Attribute
{
    string name;
    public double version;

    public Author(string name)
    {
        this.name = name;
        version = 1.0;  // Default value
    }

    public string GetName()
    {
        return name;
    }
}

[Author("H. Ackerman")]
private class FirstClass
{
    // ...
}

// No Author attribute
private class SecondClass
{
    // ...
}

[Author("H. Ackerman"), Author("M. Knott", version = 2.0)]
private class ThirdClass
{
    // ...
}

class TestAuthorAttribute
{
    static void Main()
    {
        PrintAuthorInfo(typeof(FirstClass));
        PrintAuthorInfo(typeof(SecondClass));
        PrintAuthorInfo(typeof(ThirdClass));
    }

    private static void PrintAuthorInfo(System.Type t)
    {
        System.Console.WriteLine("Author information for {0}", t);
        System.Attribute[] attrs = System.Attribute.GetCustomAttributes(t);  // reflection

        foreach (System.Attribute attr in attrs)
        {
            if (attr is Author)
            {
                Author a = (Author)attr;
                System.Console.WriteLine("   {0}, version {1:f}", a.GetName(), a.version);
            }
        }
    }
}

Output

---

Author information for FirstClass
H. Ackerman, version 1.00
Author information for SecondClass
Author information for ThirdClass
H. Ackerman, version 1.00
M. Knott, version 2.00

Definition and Uses of a Digital Certificate

 

A Digital Certificate allows you to establish your credentials when doing business or other transactions on the Web. You can present a Digital Certificate electronically to prove your identity or your right to access information or services online.
Digital Certificates, bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. A Digital Certificate makes it possible to verify someone's claim that they have the right to use a given key, helping to prevent people from using phony keys to impersonate other users. Used in conjunction with encryption, Digital Certificates provide a more complete security solution, assuring the identity of all parties involved in a transaction.
A Digital Certificate is issued by a Certification Authority (CA) and signed with the CA's private key. A Digital Certificate typically contains the following:

• Owner's public key
• Owner's name
• Expiration date of the public key
• Name of the issuer (the CA that issued the Digital Certificate)
• Serial number of the Digital Certificate
• Digital signature of the issuer

Uses of a Digital Certificate

If you are running a virtual mall, electronic banking website or any other electronic services website then customers may abandon your website due to concerns about privacy and security. A server with its own Digital Certificate assures users that the server is run by the organisation it claims to be affiliated with and that the content provided is legitimate.
Digital Certificates can be used for a variety of electronic transactions including e-mail, electronic commerce, groupware and electronic funds transfers.
For example: A customer shopping at an electronic mall requests the Digital Certificate of the server to authenticate the identity of the mall operator and the content provided by the merchant. Without authenticating the server, the shopper would not trust the operator or merchant with sensitive information like a credit card number. The Digital Certificate is instrumental in establishing a secure channel for communicating any sensitive information back to the mall operator.

Indexers, Partial Class And Partial Method

 

View more presentations from Gopal Ji Singh

Singleton pattern

In software engineering, the singleton pattern is a design pattern used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects.

There is criticism of the use of the singleton pattern, as some consider it an anti-pattern, judging that it is overused, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application.^{[1][2][3][4][5][6]}

In C++ it also serves to isolate from the unpredictability of the order of dynamic initialization, returning control to the programmer.

Common uses

• The Abstract Factory, Builder, and Prototype patterns can use Singletons in their implementation.
• Facade Objects are often Singletons because only one Facade object is required.
• State objects are often Singletons.
• Singletons are often preferred to global variables because:
  • They don't pollute the global name space (or, in languages with namespaces, their containing namespace) with unnecessary variables.^[7]
  • They permit lazy allocation and initialization, whereas global variables in many languages will always consume resources.

  • Structure

    

    Implementation

    Implementation of a singleton pattern must satisfy the single instance and global access principles. It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made private. Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed. Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton.
    The singleton pattern must be carefully constructed in multi-threaded applications. If two threads are to execute the creation method at the same time when a singleton does not yet exist, they both must check for an instance of the singleton and then only one should create the new one. If the programming language has concurrent processing capabilities the method should be constructed to execute as a mutually exclusive operation.
    The classic solution to this problem is to use mutual exclusion on the class that indicates that the object is being instantiated.
    

    Example

    The Java programming language solutions provided here are all thread-safe but differ in supported language versions and lazy-loading. Since Java 5.0, the easiest way to create a Singleton is the enum type approach, given at the end of this section.
    

    Lazy initialization

    public class Singleton {
            private static Singleton _instance = null;
     
            private Singleton() {   }
     
            public static synchronized Singleton getInstance() {
                    if (_instance == null) {
                            _instance = new Singleton();
                    }
                    return _instance;
            }
    }
    

    Traditional simple way

    This solution is thread-safe without requiring special language constructs, but it may lack the laziness of the one above. The INSTANCE is created as soon as the Singleton class is initialized. That might even be long before getInstance() is called. It might be (for example) when some static method of the class is used. If laziness is not needed or the instance needs to be created early in the application's execution, or your class has no other static members or methods that could prompt early initialization (and thus creation of the instance), this (slightly) simpler solution can be used:
    

    public class Singleton {
            private static final Singleton instance = new Singleton();
     
            // Private constructor prevents instantiation from other classes
            private Singleton() { }
     
            public static Singleton getInstance() {
                    return instance;
            }
    }
    

    
    

    For More Details Please Visit: 

    http://en.wikipedia.org/wiki/Singleton_pattern

Understanding the Microsoft Windows DNA Architecture

Central to Windows DNA is the concept that applications should be logically separated into partitions, called tiers. According to Avalani, this benefits developers in several ways.

"Partitioning an application increases its scalability -- in other words, the software's ability to support a large number of simultaneous users," Avalani says. " It also makes the application more manageable and easier to update.

The three tiers of Windows DNA are:

•	Presentation, or user interface
•	Business logic
•	Data storage

It's important to note that these three tiers are separations within the application. The deployment of the application can span any number of computers. Avalani cites the example of a mobile worker using a laptop computer. A Windows DNA-based application can run on that single computer, providing the benefit of access to the application at any time or any place. In the case of a large, electronic commerce Web site, the Windows DNA-based application might be distributed across many servers to meet that particular company's scalability requirements.

" This explains why people sometimes talk about Windows DNA as an n-tier

or multi-tier architecture, "Avalani points out." They are referring to the ability to deploy a Windows DNA-based application over any number of physical computers. "

COM: The Cornerstone of Windows DNA

Avalani notes that Windows DNA is based on a programming model called COM (Component Object Model). The COM model has come into widespread use since its introduction by Microsoft and it is an integral part of many Microsoft applications and technologies, including Internet Explorer and the Office suite of applications.

Unlike traditional software development, which required each application to be built from scratch, COM allows developers to create complex applications using a series of small software objects. Much like cars or houses are built with standardized "parts," COM lets developers make portions of their applications using components. For example, Avalani says, a component might be a tax calculation engine or the business rules for a price list. A growing number of third-party vendors sell COM components.

This approach speeds up the development process by allowing several teams to work on separate parts at the same time. Developers can also reuse components from one project to the next, and they can easily swap out or update a particular component without affecting other portions of the application. COM also offers the advantage of programming language independence. That means developers can create COM components using the tools and languages they're familiar with, such as Visual Basic, C, C++ and Java.

"An easy way to look at it is that COM serves as the glue between the tiers of the architecture, allowing Windows DNA applications to communicate in a highly distributed environment," Avalani explains. 

For More Details Please Visit: http://www.microsoft.com/presspass/features/1999/02-23dna2.mspx

Making great Metro style apps

196 out of 223 rated this helpful  

[This documentation is preliminary and is subject to change.]

Metro style apps are the focal point of the user experience on Windows 8 Consumer Preview, and great Metro style apps share an important set of traits that provide a consistent, elegant, and compelling user experience.
At this point, you might be asking, "OK, so what are Metro style apps and how do they differ from desktop apps?" Metro style apps are immersive and chromeless, filling the entire screen so there are no distractions. Metro style apps work together, making it easy to search, share, and send content between them. When users are connected to the internet, their apps show them the latest content so that they can stay up to date. With a connected account, users can download apps and use them on any Windows device.
You can create Metro style apps using the languages you're most familiar with, like JavaScript, C#, Visual Basic, or C++. And Windows Store delivers everything you need to sell your apps and everything your users need to get apps.

For More Details please visit: http://msdn.microsoft.com/library/windows/apps/hh464920.aspx

Model–view–controller ( M V C )

 

Model/view/controller (MVC) is a software architecture,^[1] currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns).
Use of the Model/View/Controller (MVC) pattern results in applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements.

Concepts

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.
The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A view port typically has a one to one correspondence with a display surface and knows how to render to it.
The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.

An MVC application may be a collection of model/view/controller triads, each responsible for a different UI element. The Swing GUI system, for example, models almost all interface components as individual MVC systems.

MVC is often seen in web applications where the view is the HTML or XHTML generated by the application. The controller receives GET or POST input and decides what to do with it, handing over to domain objects (i.e. the model) that contain the business rules and know how to carry out specific tasks such as processing a new subscription, and which hand control to (X)HTML-generating components such as templating engines, XML pipelines, Ajax callbacks, etc.
The model is not necessarily merely a database; the 'model' in MVC is both the data and the business/domain logic needed to manipulate the data in the application. Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple applications that have little domain logic there is no real distinction to be made. Active Record is an accepted design pattern that merges domain logic and data access code — a model which knows how to persist itself.

For More Details Please Visit: http://en.wikipedia.org/wiki/Model-view-controller