I would like to write a few words about project management, note that I'm not a certified manager in any way and that you can contradict each and every word I write as long as you have arguments.
Whenever you start or join a new project you should keep in mind that you must be very organized about what you do and how you do, a list of things you should never do:
1. do not write code just to make stuff work, make it as elegant as you can;
2. do not write lousy identifier(variables, classes, constants, methods, etc.) names, by lousy I mean that the name should specify it's scope;
3. do not write anything without a comment unless it's something very simple that doesn't need comment, i.e. aVariable := aValue or aVariable := TSomeClass.Create;
4. try do avoid long method code, if you have a 30-50-100 or more lines of code in a method(procedure, function) it can get confusing trying to understand what goes down, not to mention point 2. or 3. that would make you wanna scream like a little girl;
5. oups! project needs updates or modifications, make sure you understand everything you need to do before you start, ummm... wait! I have to fix bugs made by other developer(s), how would you feel if they haven't done anything I wrote in points from 1. to 5.?
And now a list of arguments, each point is a reference to above list:
1. if you write code just to make stuff work, I would like to see you struggle to understand what "da' heck did I wrote here...?" or other developer(s) would probably hang you :)
2. lousy identifier names is one of the best way to make other coworkers want skin you alive, i.e. think of a methods that has this variables sData, iW, iH, are this logical enough to understand their scope? how about this: strData, intWidth, intHeight? depending on the code convention you have with coworkers or boss;
3. I have a unit with 2.000 lines of code written by me(or not) about 5-6 months ago, no freaking comment, no nothing, and have 2 days to get a task completed, what da' heck should I do? at this point a drink would be the best choice!
4. another problem would be a long code that do not fit in your screen, I mean you cannot see the entire method code without scrolling, this can have sever consequences you'll see;
5. if you're afraid to ask the team leader or coworkers about what exactly you need to do, then my friend you have serious issues, understanding your tasks is a must, even though you have big experience as a programmer, it's still wise to understand your tasks.
From what I saw(until now) most developers(not necessarily Delphi developers) tend not to respect the above mentioned, let me tell you what happens:
You get project(at first you do not know how big it will be, no one knows, not even the investors) you start writing messy code, it's Okay you just started, there is time to fix anything, you wish to make a good impression by "making stuff work fast", time passes, you get paid, everyone gets paid, now 1-2 years have passed, you project is a mess -- no one thought that it will take so long but everybody is happy that it did -- now when you look at your code 20-40-60 thousand lines of messy and poor commented code, you just want to scream like a little girl and run to mommy, but you forget that everything is because of your poor management which(from my experience) it shouldn't take more than 1 hour for 8 hours of work to be done and in 1 to n years you don't need to go to mommy or abandon project.
Neuerungen in 10.2 Tokyo: Professional (oder: Was alles, außer Linux!) - In den letzten Tagen bin ich häufiger gefragt worden, welche Neuerungen es denn in Delphi 10.2 Tokyo gibt, die *nicht* die Enterprise bzw die Linux-Unter...