Você pode ver este post em português também.
- Graduate yourself. I know people that leave the graduation behind and are going well, and I can garantee that this kind of people is rare. Different from @eminetto, I joined to the graduation at 2004 with some experience on IT (I started at 1997). And even tought the graduation expanded (better, it did try and applied) knowledge on fields which I had never heard before, and it was really valuable;
- Know the business target. Spend some hours of your week following the work of the people that orbitate your systems. Yes, stop to hunt bits and bytes and try to understand the ecosystem around them;
- Do the good, the best can be done later. Stop to spend time (and resources) to deliver that piece of software (or a change, or that model, or even that architecture, etcetera.) in a great degree of details. Reach the required goal. If you did it, deliver it. You can organize yourself to, at intervals of time, review your work and fits it to the current necessity (ok, I admit I’m still looking then this item 100% of the time…);
- Fall in love with your work. Nowadays I believe that is the only way to make us to think if we can do something that we already do, better. Look for more details about the programming language you are using. Learn more about the database systems. Learn about standards (seriously, there are standards for many things in software and use them helps a lot!). Learn more about the business to which your software meets;
- Serve the man, not to machines. This small excerpt of the vow of the engineer says a lot to me. I’m a GNU/Linux user since 2001, but I offered a lot of support for MS-Windows, I taught classes about MS-Office, I managed several MS-Windows servers, I used MS-Windows a lot. I’ve programmed with Clipper, C, Delphi, C#, ASP.NET, ASP, and nowadays I’m a PHP programmer. I’ve worked with Progress, MS-SQL Server, and nowadays I’m currently working with Oracle and MySQL. I’ve integrated systems with EDI (come on!!), today the fashion is Web services and REST. The way (technology) is important, but don’t forget the purpose, objectives and requirements that must be met. For the customer, is what matters;
- Documentation is, definitely, important. When your boss (or yourself) needs to make a presentation or discuss an integration, new features, boundaries, processes, etc.. with people who have no knowledge about your code, you will agree with me. Unfortunately, nowadays, the pain is the only way that I see to make someone understand this…
OK, that’s it. I suggest, so insistent, that you read the post from Elton. There are ideas there that I just tried to keep there, avoiding repetitions.
See you! 😉