azizkhani.net

I know that I know nothing

The Principles of Good Programming

clock November 23, 2012 13:56 by author Administrator

The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects.

DRY - Don’t repeat yourself. - Probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction.
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.”
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal.
http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it.
http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design.
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified
http://www.sensible.com/dmmt.html

Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend.
http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else.
A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”
http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task.
http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability”
http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion - Code that has similar functionality should be found within the same component.
http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component.
http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.)
http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" Knuth.
http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time.
http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code.
http://en.wikipedia.org/wiki/Separation_of_concerns

ref:http://area.autodesk.com/blogs/chris/the_principle_of_good_programming



Introduction To Scrum

clock November 23, 2012 13:46 by author Administrator

This post is an introduction to Scrum, one of the Agile methods to drive software application implementation. Reading this post is a prerequisite to this post.

Concepts

  • Scrum projects deliver software application features iteratively.
  • Each iteration is called a sprint.
  • Scrum projects have 4 stages:
    • Planning – Definition of the vision, budget, and expectations. The first version of the product backlog should containing enough implementation items for the first sprint.
    • Staging – This is the first iteration where the requirements and product backlog created in the planning are refined.
    • Development – It is the set of sprints required to implement the project fully. It ends when the product backlog is empty.
    • Release – The final product is deployed, training is performed, documentation is finalized, etc… The release backlog can be used as the product backlog for the next release of the product.
  • There are 4 main roles in scrum projects: team member, product owner, stakeholders and scrum master:
    • A product owner is a customer representative acting as a single point of contact on the customer side.
    • A stakeholder is anyone having a vested interest in the project, providing information about requirements and participating to the decision process of features to be implemented.
    • A scrum master is a facilitator and single point of contact on the development team side. It is a support function, not a ‘controlling chief’ role. It is a mix between a team leader and a software engineering role, which does not include people management or profit & lost responsibilities.
    • A team member is a software engineer.
  • Scrum of scrum can be implemented when multiple scrum teams are working on the same large project. Scrum master and product representatives get together.
  • The product backlog is a list of features, use cases, enhancement, defect, etc… to be implemented in the project’s forthcoming sprints.
  • The release backlog is the list of features, uses cases, enhancement, defect, etc… which are postponed to the next version of the project (not next sprint).

 
Practice

  • Spring teams typically do not have more than 7 members.
  • A sprint duration is 30 days.
  • Scrum projects are client-driven. They select the features to be implemented.
  • Each sprint begins with two meetings:
    • The stakeholder meeting, with the scrum master and customer representative to re-prioritize the product backlog and update the release backlog.
    • The product owner and team meeting where tasks are created from the product backlog.
  • Each task must require between 4 and 16 hours of work. Bigger tasks must be subdivided into smaller tasks.
  • The scrum master and product owner check whether there are enough resources to support the efforts required to achieve the sprint and adjust the workload accordingly.
  • Team member pick their tasks and work on their implementations.
  • Each spring finishes with a presentation of implemented features to the stakeholders.
  • Every day, a stand-up meeting (15-20 mins) with the team members and eventually the product owner is organized in front of a white board. The following is discussed:
    • Which tasks have been achieved since the last meeting?
    • Are there new tasks? New requirements?
    • What is blocking? Any impediments?
  • If decisions have to be taken, the Scrum Master should take them quickly, within an hour if possible
  • The Scrum Master should deal quickly with any impediments and communication issues
  • Scrum teams should preferably operate from the same room

 
Conclusion

As for all Agile methods, the Scrum approach is best suited for new projects created from scratch. Over time, when successive application releases are implemented, the project can slowly transform into a continuous integration or even maintenance project, where less stakeholders input or daily supervision is required. The cogs are well oiled and operate naturally.

Reference: Introduction To Scrum



ROW LEVEL SECURITY (BEST SOLUTION?)

clock October 25, 2012 19:21 by author Administrator

 

HELP ME
here might be special rows in a database which should only visible and accessible by users with special privileges. To avoid unnecessary round-trips, we currently modify the SQL queries to join with our authorization data to get only the visible rows for the current user.

But this concepts doesn't feel 'right' to me, because we mix business code with security related code which should be orthogonal and independent from each other.

 

  • What solutions are available/possible?
  • How do you implement row-level security (especially in combination with hibernate)?

The idea is that you can implement row level functionality in two ways: directly setting restrictions in your repository or binding the restrictions via AOP. The latter is preferred because security layer should be separated from business logic (orthogonal concerns).

 

In Hibernate you can use the concept of filters which are applied transparently and repository doesn't know about them. You can add such filters via AOP. The other way is intercepting session.createCriteria() and adding Restrictions to the Criteria transparently using AOP.

 



Spring and hibernate 4 integration

clock October 25, 2012 18:29 by author Administrator

add this dependancy

 

    <!-- Hibernate framework -->
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>4.1.4.Final</version>
        </dependency>
        <dependency>
            <groupId>javax.persistence</groupId>
            <artifactId>persistence-api</artifactId>
            <version>1.0.2</version>
        </dependency>
        <!-- end hibernate -->

 

and then change spring configuration like this

 



    <tx:annotation-driven transaction-manager="hibernateTransactionManager" />
    <bean id="dataSource"  class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName" value="${hibernate.connection.driver_class}" />
        <property name="url" value="${hibernate.connection.url}" />
        <property name="username" value="${hibernate.connection.username}" />
        <property name="password" value="${hibernate.connection.password}" />
    </bean>
    <bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="mappingLocations">
            <list>
                <value>/WEB-INF/classes/hibernate/**/*.hbm.xml</value>
            </list>
        </property>

        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.connection.driver_class"> ${hibernate.connection.driver_class}</prop>
                <prop key="hibernate.connection.url"> ${hibernate.connection.url}</prop>
                <prop key="hibernate.connection.username"> ${hibernate.connection.username}</prop>
                <prop key="hibernate.connection.password"> ${hibernate.connection.password}</prop>
                <!-- <prop key="hibernate.connection.internal_logon"> ${hibernate.connection.internal_logon}</prop> -->
                <prop key="hibernate.dialect"> ${hibernate.dialect}</prop>
                <prop key="hibernate.show_sql"> ${hibernate.show_sql}</prop>
                <prop key="hibernate.hbm2ddl.auto"> ${hibernate.hbm2ddl_auto}</prop>
                <!-- <prop key="hibernate.default_schema"> ${hibernate.default_schema}</prop> -->
            </props>
        </property>
    </bean>

    <bean id="hibernateTransactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
    </bean>

 

and now

 

package org.azizkhani.dao;

import java.util.List;

import org.azizkhani.core.QueryResult;

public interface IGenericRepository<T> {
    public List<T> getAll();
    public List<T> getAll(String where, String order, int pageNumber,int pageSize);
    public QueryResult<T> getAllGrid(String where, String order, int pageNumber,int pageSize);
    public T loadByEntityId(int entityId);
    public T single(String where);
    public void add(T entity);
    public void delete(T entity);
    public void deleteByEntityId(int entityId);
    public void update(T entity);
    public int count();
}

 

implementation

 

package org.azizkhani.dao.impl.hibernate;

import java.util.List;

import org.azizkhani.common.utility.HQLUtility;
import org.azizkhani.core.QueryResult;
import org.azizkhani.dao.IGenericRepository;
import org.hibernate.Criteria;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;

@Repository
public abstract class GenericRepository<T>  implements IGenericRepository<T> {
    protected Class<T> domainClass = getDomainClass();

    protected abstract Class<T> getDomainClass();
   
    @Autowired
    private SessionFactory sessionFactory;
   

    @Override
    public List<T> getAll() {
        Criteria criteria = getSession().createCriteria(domainClass.getName());
        return criteria.list();
    }

    public Session getSession() {
        try {
            return sessionFactory.getCurrentSession();
        } catch (Exception e) {
            System.out.println(e.getMessage().toString());
        }
        return sessionFactory.openSession();
    }

    public QueryResult<T> getAllGrid(String where, String order, int pageNumber, int pageSize) {
        Session session = getSession();
        StringBuffer jql = new StringBuffer("from " + domainClass.getName()
                + " e ");
        HQLUtility.toHQL(jql, where, order);
        Query query = session.createQuery(jql.toString());
        if (pageSize > 0)
        {
            query.setFirstResult(pageNumber * pageSize);
            query.setMaxResults(pageSize);
        }
        List<T> list = query.list();

        StringBuffer jqlCount = new StringBuffer("select count(*)  from "
                + domainClass.getName() + " e ");
        HQLUtility.toHQL(jqlCount, where, "");
        int count = ((Long) getSession().createQuery(jqlCount.toString())
                .uniqueResult()).intValue();

        return new QueryResult<T>(pageNumber, count, pageSize, list);
    }

    @Override
    public List<T> getAll(String where, String order, int pageNumber, int pageSize) {
        Session session = getSession();
        StringBuffer jql = new StringBuffer("from " + domainClass.getName()
                + " e ");
        HQLUtility.toHQL(jql, where, order);
        Query query = session.createQuery(jql.toString());
        if (pageSize > 0)
        {
            query.setFirstResult(pageNumber * pageSize);
            query.setMaxResults(pageSize);
        }
        return query.list();
    }
    @Transactional(readOnly=true)
    @Override
    public T loadByEntityId(int entityId) {
        return (T) getSession().load(domainClass, entityId);
    }

    @Override
    public T single(String where) {
        return null;
    }

    @Override
    public void add(T entity) {
        Session session = getSession();
        session.beginTransaction();
        session.save(entity);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public void delete(T entity) {
        getSession().delete(entity);
    }

    @Override
    public void deleteByEntityId(int entityId) {
        Session session = getSession();
        session.beginTransaction();
        Object obj = session.load(domainClass, entityId);
        session.delete(obj);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public void update(T entity) {
        Session session = getSession();
        session.beginTransaction();
        session.update(entity);
        session.getTransaction().commit();
        session.close();
    }

    @Override
    public int count() {
        int count = ((Long) getSession().createQuery(
                "select count(*) from " + domainClass.getName()).uniqueResult())
                .intValue();
        return count;
    }
}



 

 





creating and manipulating Microsoft Office(Word docx, Powerpoint pptx, and Excel xlsx) in java

clock October 25, 2012 18:03 by author Administrator

Create complex Word (.docx) documents programatically with docx4j

lvdpal's  Creating Word documents with Docx4j, which covers tables in some detail

Jos Dirksen's  Create complex Word (.docx) documents programatically with docx4j

Joshua Born's  Creating Word Documents in Java

Glen Smith's  Creating Word docx documents dynamically from Grails (or Java)

  Spring MVC (Russian)

java api

http://poi.apache.org/

http://www.docx4java.org/trac/docx4j



Decorator Design Pattern Case Study

clock October 24, 2012 22:36 by author Administrator



Decorator pattern is basically a way to extend functionality of an object by decorating with other objects which can wrap the target object and add their own behavior to it. If you never used or heard of decorators, I highly recommend reading chapter 3 of Head First Design Patterns.

Pretty much like other patterns mentioned in my posts before, JavaEE has an easy an elegant way to use the decorator pattern. Lets start with a simple stateless session bean.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    
    public void startService(){
        System.out.println("do something important here...");
    }
}

To start implementing the decorator pattern, we need an interface so we can bind the decorators and the object to be decorated together.


package com.devchronicles.decorator;

/**
 *
 * @author murat
 */
public interface ServiceInterface {
    public void startService();
}

The interface has the method which the decorators will add functionality on. Next we need some changes on our existing EventService bean to make it decoratable.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService implements ServiceInterface{
    
    public void startService(){
        System.out.println("do something important here...");
    }
}


Now we are ready to add as much as decorator we need. All we need to do is to annotate our class, implement the ServiceInterface and to inject our service delegate.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator //declares this class as a decorator
public class DecoratorService implements ServiceInterface{ //must implement the service interface
    
    @Inject //inject the service
    @Delegate //and annotate as the delegate
    ServiceInterface service;

    @Override
    public void startService() { //implement the startService method to add functionality
        System.out.println("decorating the existing service!");
        service.startService(); //let the execution chain continue
    } 
}

Several decorators can be using the service interface.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator
public class Decorator2Service implements ServiceInterface{
     @Inject
    @Delegate
    ServiceInterface service;

    @Override
    public void startService() {
        System.out.println("decorating the service even further!!!");
        service.startService();
    }
}

Most of the configuration can be done via annotation in JavaEE6. However we still need to add some xml configuration to make decorators work. It might seem disappointing since we already annotated our decorators but still the configuration is pretty simple and needed in order to declare the order of execution. Add the following lines to the empty beans.xml.


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
           <decorators>
               <class>com.devchronicles.decorator.DecoratorService</class>
           <class>com.devchronicles.decorator.Decorator2Service</class>
           </decorators>
</beans>

When the startService method of our EventService is executed, the decorators will decorate the ejb and add their own behavior to the execution.

...

INFO: WEB0671: Loading application [Decorator] at [/Decorator]
INFO: Decorator was successfully deployed in 2,534 milliseconds.
INFO: decorating the existing service!
INFO: decorating the service even further!!!
INFO: do something important here...
...

Reference: JavaEE Revisits Design Patterns: Decorator



Factory Design Pattern Case Study

clock October 18, 2012 21:52 by author Administrator

I had a job to check our project code quality. And have to report it back to my team leader for any obstacle that i found in the project. I found a lot of leaks and i think would be good to be discussed on the blog. Not to mock the author, but to learn and improve ourselves together.

Like this code, this is the part that i found in our code.

 

public ContactInfoBean(final Reseller resellerInfo) {

       switch(resellerInfo.getType()) {

           case PROGRAM_CONTACT:
                   readExecutiveInfo(resellerInfo);
               break;
           case FILE_CONTACT:
                  readOperationalInfo(resellerInfo);
               break;
           default:

               break;

       }

   }

The code works fine, and do its job pretty well. But some problem will appear by using this code-style. This class will grow tailing the biz changes, as usual, the bigger one class, the “merrier” to maintain it is. And most likely this class, will be having more than one purpose, can be called low-cohesion.

Better OOP Approach

Well the better approach for the case above would be using the Factory Design Pattern. We can let the factory of READER to generate every single instance according to their type. It would be easier to grow the instance type, since we just need to create a new class and do a little modification in the Factory class. The caller class, wont grow and will stand still at its current shape.

public interface InfoReader {

      public void readInfo();

}


public class ExecutiveReader implements InfoReader {

      public void readInfo() {
           // override
      }

}

 


public class OperationalReader implements InfoReader {

        public void readInfo() {
         // override
        }

}

And The Factory

public class InfoReaderFactory {

      private static final int PROGRAM_CONTACT = 1;

      private static final int FILE_CONTACT = 2;

      public static InfoReader getInstance(Reseller resellerInfo) {

              InfoReader instance = null;

             switch (resellerInfo.getType()) {

                 case PROGRAM_CONTACT:

                       instance = new ExecutiveReader();

                    break;

                 case FILE_CONTACT:

                     instance = new OperationalReader();

                   break;

                default:

                    throw new IllegalArgumentException('Unknown Reseller');

      }

     return instance;

   }

}

And now The Caller

InfoReader reader = InfoReaderFactory.getInstance(resellerInfo);

reader.readInfo();


The Benefits

With the Factory Design Pattern to handle this case, we can achieve some benefits,

  • Specifying a class for one task, means, easier to maintain since one class is for one purpose only (modularity/High Cohesion). i.e: Operational Reader is only to read data for Operational only, no other purpose. Just in case, one day in the future we need another Reader (say: NonOperationalReader). We just need create a new Class that extends (or implements) the InfoReader class and then we can override our own readInfo() function. This Caller class will have no impact. We just need to do some modification in the Factory code.


public class InfoReaderFactory {
    private static final int PROGRAM_CONTACT = 1;
    private static final int FILE_CONTACT = 2;
    private static final int NEW_READER = 3;

    public static InfoReader getInstance(ResellerInfo resellerInfo) {
        InfoReader instance = null;
        switch (resellerInfo.getType()) {
          case PROGRAM_CONTACT:
              instance = new ExecutiveReader();
              break;
          case FILE_CONTACT:
              instance = new OperationalReader();
              break;
          case NEW_READER:
              instance = new NonOperationalReader();
              break;
          default:
              throw new IllegalArgumentException('Unknown Reseller');
        }
        return instance;
    }
}

Higher Reusability of Parent’s Component (Inheritance): Since we have parent class (InfoReader), we can put common functions and thingies inside this InfoReader class, and later all of the derivative classes (ExecutiveReader and OperationalReader) can reuse the common components from InfoReader . Avoid code redundancy and can minimize coding time. Eventhough this one depends on how you do the code and cant be guaranteed.


But, It’s Run Perfectly, Should We Change It?

Obviously the answer is big NO. This is only the case study and for your further experience and knowledge. OOP is good, do it anywhere it’s applicable. But the most important thing is, if it’s running, dont change it. It would be ridiculous if you ruin the entire working code just to pursue some OOP approach. Dont be naive also, no one can achieve the perfect code. The most important is we know what is the better approach.

 

 

ref:http://namingexception.wordpress.com/2012/10/17/case-study-factory-design-pattern/



linq order by desc and get first row

clock October 15, 2012 21:46 by author Administrator

SortedDictionary<int, int> result = new SortedDictionary<int, int>();

int max=result.OrderByDescending(t => t.Value).FirstOrDefault().Key;



Things Great Engineers (almost) Never Say

clock October 12, 2012 22:48 by author Administrator
  • “I’ve used _____ but I have no idea how it works”
    – Great engineers gained their skills through probing and curiosity.  They go ‘under the hood’ of the products they use just to understand how things work, even if that information will never be very useful to them.  It is unclear whether this need to dig deeper is a choice or a compulsion, but it seems that it is a trait of the best talent.
  • “______ works, I just don’t know how to explain it”
    – Not only do the greats know how things work, but most of them derive genuine pleasure in telling others why and how things workThis is often true even if the other person doesn’t care to know.  Over the course of my career I’ve listened to engineers talk for thousands of hours, and in almost all cases my conversations with the most talented go much longer.  I actually made a point of scheduling an extra fifteen to twenty minutes on my calendar when I will be speaking to someone who appears to be great on paper, as I know that the person will go deep into some technical details and nuances that will come up in conversation.
  • “I will need ______ (tool/condition) to complete this task”
    – The masters of development will have the ability to improvise and adjust on the fly to arrive at a solution in non-ideal conditions.  When you hear of engineers being compared to MacGyver they are speaking of this very rare skill.  Greats will figure out a way based on minimal resources and will be aware of alternatives to their first choice of tool.
  • “I’ve learned all I want/will ever need to know about ________ “
    – Continuous learning and improvement is probably the most obvious differentiation between the good and the great.  They don’t just get to a high level and then rest.  The best engineers understand that industry progress causes them to never stop learning, and if they are not gaining enough new knowledge in their day jobs they will invest the time to learn during off hours.
  • “There is no solution” – The greats will continue looking at a problem different ways to come up with an answer instead of conceding.  This characteristic can be both a blessing and a curse.
  • “I hate programming” - At times a great engineer will hate their job or employer, but their love of solving problems with code is what brought them to this skill level.
  • “I’m an expert in _____” (when it’s not true, and even sometimes when it is true) – The strongest engineers have no need or desire to lie or exaggerate the depth of their skills.  Much of the great talent will be reluctant to say they are an expert in anything, as they are aware others could know more.
  • “I don’t understand the business” – The stronger engineers will always want to know how their code impacts the employer and is able to describe their contribution and value to the organization.
  • “I don’t pay particular attention to industry trends” – Being both great and relevant (in demand) is only possible if you keep an eye on where the industry is headed.  When speaking to talented engineers, the topic of which new technologies are actually viable and which are a passing phase will often come up.

If you find yourself using any of these lines on a regular basis, give some thought to why.  Quoting one of these lines in a job interview could be a serious mistake.

 

 

Reference: Things Great Engineers (almost) Never Say



kent beck

clock October 7, 2012 23:35 by author Administrator

when my search space gets big and uncertain i need a pen and paper, not a computer



About the author

 Welcome to this web site . This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog


Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...

RecentPosts

Month List

Sign In