May 27, 2008 at 01:265 tips for IT-specialists on the example of layout
The epidemic of layout tips has reached me ( thanks to Jura Artyukh ) - I will share them with pleasure. These tips are quite general and, in principle, apply to many IT specialties - the layout here is used simply as an example.
Quite often, when the next bug occurs in a certain browser, I want to solve the problem as soon as possible, and this opportunity appears. The most commonplace example: a block is shifted by a few pixels in IE, because you can move it back in IE style (or hack) and not bother. The desire is quite natural - the deadlines, as always, are running out, the result at the end is the same, and I would not say thank you for the extra effort spent - the payment would remain the same.
The fallacy of this approach is that the problem is solved without a clear understanding of why it occurred.. Which in turn leads to its appearance again and again in the future. The desire to achieve immediate results easily and simply translates into a loss of effectiveness in all subsequent projects. Moreover, such an attitude hinders your professional development in this area, which in the long run is much more important than the result of the current project.
If you postpone the result and take the time to really figure out why exactly this happened, in what other cases does this bug appear, what are all the ways to solve it (all, not just one), in hundreds of similar situations in the future this bug ( in all its manifestations, and not just in this particular one) most likely it simply will not arise, because you possess the necessary knowledge for its easy prevention. And if it does, it can be instantly resolved. With experience with this approach, you begin to write code that immediately works in all browsers, almost on the machine, without hesitation - ask your friends the gurus, they will confirm.
The same goes for decision making. Do not blindly copy a piece of code after you find a solution by Google - take a couple of minutes to find an explanation of why this works.
And yet - this does not mean that you have to violate the deadlines for the sake of professional development. Just learn to take this time into account when agreeing a timeline with the customer.
For each individual task in the layout, there are many ways to solve it. Each has its own advantages and disadvantages, cases where they fit perfectly and those where they do not fit at all. If you are just an amateur, you can focus on what suits you. But if you are a professional, you must know and be able to apply them all .
If in solving a specific problem (for example, image replacement or multi-column layout) you were satisfied with one specific method - do not stop there. Keep trying others. Read blogs about new ones and apply them too. You'll get valuable experience and will gain in the business flexibility . And flexibility - the ability to adapt to changing conditions - is an extremely important professional quality, which ultimately will win you a lot of time.
In particular, by the way, this concerns the choice of JavaScript framework. Holivars bred amateurs about this - a good front-end programmer can easily apply any of them, because thanks to his experience he knows the characteristics of each and the principles by which they are created and work. (It is also worth noting separately from the council that specifically in this matter it is much more important to understand the JavaScript programming language itself - it is much more powerful and interesting than it seems at first glance.)
Take web standards and semantics as an example. These are not indestructible commandments - these are tools created for specific purposes. If you are obsessed with them just because your colleagues are telling you about it - without thoroughly understanding why, what, and in which case it is necessary to comply - you will not be able to put them into practice correctly.
For example, a man made multi-level drop-down menu, CSS-only, and boasts the fact that it made menus available (accessible) - now they will be able to take advantage of people with javascript disabled and users of screen reader'ov. At the same time, he does not realize that contrary to the common myth, screen readers fully support JavaScript and respond to CSS in certain cases (for example, many of them do not see elements hidden using "display: none"), and that they will not be able to use this solution as users of screen readers, as well as all other people who do not navigate with the mouse (for example, only from the keyboard) - all CSS-only dropwdown menu solutions are tightly tied to mouse events. Not only that - the lack of delay in the appearance and disappearance of the menu will cause a lot of trouble for people with poor eyesight or impaired motor function (for example, Parkinson's disease) - figs you will point to the desired item. There you have it.
The opposite example: the developer spends a lot of time making the sophisticated web 2.0 application ideal in terms of semantics, not realizing that for people with disabled CSS or JavaScript, it will never be of any use in view of its specificity, but to search engines indexing access is denied because pages are accessible only to registered users.
Another example: HTML / CSS validation. According to a certain Doctype, validity in itself does not bring any benefit to the project, does not make it more accessible and semantic, and does not say anything about the quality of the layout. This is just a tool, and they need to be able to use, not blindly obey. For example, I personally bring my projects in line with XHTML 1.0 Strict, but not because it’s cool, it elevates me to other developers and gives me a good reason to criticize, but simply because I personally feel so comfortable for certain reasons (but Van Sagalaev does not like this option and he is also absolutely right). Unfortunately, I often observe the opposite. By the way: an article on this topic .
Get to the bottom of the tools you use. Know when to apply them, and when not to. If you apply - know well why.
If your customer (or boss, or manager) makes a completely stupid demand, you don’t need to fulfill it, clenching your teeth and swearing under your nose. Take the time to reasonably explain why this solution is ineffective.
Of course, in such a situation, it is easiest to just think that the customer is an idiot and stop the discussion, but such an attitude will not benefit either you, the customer, or the ongoing project. Be above it. Look first of all at yourself, and then at others. In this case, this means first of all thinking what was wrong with your argument and how it can be made more convincing. Even if, after listening to your arguments, he decides to do his own thing, he will do it with an awareness of all the consequences, and trust and respect for you as a specialist will increase - in any case , both sides win .
In the case of layout, the same applies to designers. A good designer should know both the complexity of the layout of certain things and the features of the Web that he can use. Therefore, when you, as a typesetter, actively interact with designers, and not just make out what you draw, both of you grow professionally, and the project together with you ultimately wins.
A person can achieve truly meaningful results only in those deeds that he really loves, with which he is passionate and engaged with all his soul. Look for things that truly captivate in your work, and do it no matter what . If you really want to write ultra-semantic code to the smallest detail even where it is not needed at all for many reasons - write. If you really like extreme CSS experiments, for which the boss kicks you all the time, go ahead anyway. Loss of enthusiasm ultimately means loss of skill. Availability - continuous self-improvement and excellent results.
Thanks for attention. :)
update: I pass the baton with a theme extension (this has already become boring a bit) - abstractioneer'five tips on Ruby / Rails, dobrych - on Python / Django, ld100 - on project management.
1. Do not look for easy ways to solve problems.
Quite often, when the next bug occurs in a certain browser, I want to solve the problem as soon as possible, and this opportunity appears. The most commonplace example: a block is shifted by a few pixels in IE, because you can move it back in IE style (or hack) and not bother. The desire is quite natural - the deadlines, as always, are running out, the result at the end is the same, and I would not say thank you for the extra effort spent - the payment would remain the same.
The fallacy of this approach is that the problem is solved without a clear understanding of why it occurred.. Which in turn leads to its appearance again and again in the future. The desire to achieve immediate results easily and simply translates into a loss of effectiveness in all subsequent projects. Moreover, such an attitude hinders your professional development in this area, which in the long run is much more important than the result of the current project.
If you postpone the result and take the time to really figure out why exactly this happened, in what other cases does this bug appear, what are all the ways to solve it (all, not just one), in hundreds of similar situations in the future this bug ( in all its manifestations, and not just in this particular one) most likely it simply will not arise, because you possess the necessary knowledge for its easy prevention. And if it does, it can be instantly resolved. With experience with this approach, you begin to write code that immediately works in all browsers, almost on the machine, without hesitation - ask your friends the gurus, they will confirm.
The same goes for decision making. Do not blindly copy a piece of code after you find a solution by Google - take a couple of minutes to find an explanation of why this works.
And yet - this does not mean that you have to violate the deadlines for the sake of professional development. Just learn to take this time into account when agreeing a timeline with the customer.
2. Do not be afraid to try new solutions.
For each individual task in the layout, there are many ways to solve it. Each has its own advantages and disadvantages, cases where they fit perfectly and those where they do not fit at all. If you are just an amateur, you can focus on what suits you. But if you are a professional, you must know and be able to apply them all .
If in solving a specific problem (for example, image replacement or multi-column layout) you were satisfied with one specific method - do not stop there. Keep trying others. Read blogs about new ones and apply them too. You'll get valuable experience and will gain in the business flexibility . And flexibility - the ability to adapt to changing conditions - is an extremely important professional quality, which ultimately will win you a lot of time.
In particular, by the way, this concerns the choice of JavaScript framework. Holivars bred amateurs about this - a good front-end programmer can easily apply any of them, because thanks to his experience he knows the characteristics of each and the principles by which they are created and work. (It is also worth noting separately from the council that specifically in this matter it is much more important to understand the JavaScript programming language itself - it is much more powerful and interesting than it seems at first glance.)
3. Do not obey tools. Use them.
Take web standards and semantics as an example. These are not indestructible commandments - these are tools created for specific purposes. If you are obsessed with them just because your colleagues are telling you about it - without thoroughly understanding why, what, and in which case it is necessary to comply - you will not be able to put them into practice correctly.
For example, a man made multi-level drop-down menu, CSS-only, and boasts the fact that it made menus available (accessible) - now they will be able to take advantage of people with javascript disabled and users of screen reader'ov. At the same time, he does not realize that contrary to the common myth, screen readers fully support JavaScript and respond to CSS in certain cases (for example, many of them do not see elements hidden using "display: none"), and that they will not be able to use this solution as users of screen readers, as well as all other people who do not navigate with the mouse (for example, only from the keyboard) - all CSS-only dropwdown menu solutions are tightly tied to mouse events. Not only that - the lack of delay in the appearance and disappearance of the menu will cause a lot of trouble for people with poor eyesight or impaired motor function (for example, Parkinson's disease) - figs you will point to the desired item. There you have it.
The opposite example: the developer spends a lot of time making the sophisticated web 2.0 application ideal in terms of semantics, not realizing that for people with disabled CSS or JavaScript, it will never be of any use in view of its specificity, but to search engines indexing access is denied because pages are accessible only to registered users.
Another example: HTML / CSS validation. According to a certain Doctype, validity in itself does not bring any benefit to the project, does not make it more accessible and semantic, and does not say anything about the quality of the layout. This is just a tool, and they need to be able to use, not blindly obey. For example, I personally bring my projects in line with XHTML 1.0 Strict, but not because it’s cool, it elevates me to other developers and gives me a good reason to criticize, but simply because I personally feel so comfortable for certain reasons (but Van Sagalaev does not like this option and he is also absolutely right). Unfortunately, I often observe the opposite. By the way: an article on this topic .
Get to the bottom of the tools you use. Know when to apply them, and when not to. If you apply - know well why.
4. Do not allow one-way communication with people with whom you work.
If your customer (or boss, or manager) makes a completely stupid demand, you don’t need to fulfill it, clenching your teeth and swearing under your nose. Take the time to reasonably explain why this solution is ineffective.
Of course, in such a situation, it is easiest to just think that the customer is an idiot and stop the discussion, but such an attitude will not benefit either you, the customer, or the ongoing project. Be above it. Look first of all at yourself, and then at others. In this case, this means first of all thinking what was wrong with your argument and how it can be made more convincing. Even if, after listening to your arguments, he decides to do his own thing, he will do it with an awareness of all the consequences, and trust and respect for you as a specialist will increase - in any case , both sides win .
In the case of layout, the same applies to designers. A good designer should know both the complexity of the layout of certain things and the features of the Web that he can use. Therefore, when you, as a typesetter, actively interact with designers, and not just make out what you draw, both of you grow professionally, and the project together with you ultimately wins.
5. Learn how to find more good in your chosen business and focus on it.
A person can achieve truly meaningful results only in those deeds that he really loves, with which he is passionate and engaged with all his soul. Look for things that truly captivate in your work, and do it no matter what . If you really want to write ultra-semantic code to the smallest detail even where it is not needed at all for many reasons - write. If you really like extreme CSS experiments, for which the boss kicks you all the time, go ahead anyway. Loss of enthusiasm ultimately means loss of skill. Availability - continuous self-improvement and excellent results.
Thanks for attention. :)
update: I pass the baton with a theme extension (this has already become boring a bit) - abstractioneer'five tips on Ruby / Rails, dobrych - on Python / Django, ld100 - on project management.