5 tips for IT-specialist on the example of layout
The epidemic of layout advice reached me too ( thanks to Yura Artyukh ) - I’ll share them with pleasure. These tips are quite general and, in principle, applicable to many IT specialties - the layout here is used simply as an example.
Quite often, in the event of the next bug in a particular browser, I want to solve the problem as soon as possible and this possibility appears. The most trivial example: a block shifts by a few pixels in IE, because you can move it back in the style for IE (or hack) and not bother. The desire is quite natural - the deadlines, as always, are tight, the result at the end is the same, and thank you for the extra effort you wouldn’t say - 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 efficiency in all subsequent projects. Moreover, such an attitude hampers your professional development in this area, which is much more important in the long term than the result of the current project.
')
If we postpone the result and take the time to really figure out why this is exactly what happened, in what other cases this bug appears, what ways are there to solve it (all, not one), in hundreds of similar situations this bug will continue ( in all its manifestations, and not only 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 solved instantly. With experience with this approach, you begin to write code that immediately works in all browsers, practically on the machine, without thinking - ask your friends gurus, they will confirm.
The same goes for decision making. Do not blindly copy a piece of code after you find a solution to Google - take a couple of minutes to find and explain why this works.
And yet - all this does not mean that you will have to break deadlines for the sake of professional development. Just learn how to take this time into account when agreeing terms 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 are perfect and those where they are not suitable at all. If you are just an amateur, you can stay on what suits you. But if you are a professional, you should know and be able to apply them all .
If in solving a specific task (for example, image replacement or multi-column layout) you are satisfied with one particular method - do not stop on it. Keep trying others. Read new blogs and use them too. You will gain valuable experience and gain flexibility in your business. And flexibility — the ability to adapt to changing conditions — is an extremely important professional quality that will ultimately gain you a lot of time.
In particular, by the way, this concerns the choice of a JavaScript framework. On this occasion, holivars are making amateurs - 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. (Another thing worth noting apart from the board is that it is much more important to understand the programming language JavaScript itself — specifically, it is much more powerful and interesting than it seems at first glance.)
Take for example web standards and semantics. These are not unbreakable commandments; they are tools created for specific purposes. If you are obsessed with them only because your colleagues are telling you about this - if you don’t understand thoroughly why, what and in what case you need to comply - you will not be able to put them right in practice.
For example, a person made multi-level CSS-only drop-down menus and praises that it made the menu accessible (accessible) - now people with javascript disabled and users of screen reader 's can use it. At the same time, he does not realize that, despite the common myth, screen readers are fully supported by JavaScript and also react to CSS in certain cases (for example, many of them do not see the elements hidden using “display: none”), and that this solution cannot be used as users of screen readers, as well as all other people who navigate not using the mouse (for example, only from the keyboard) - all CSS-only solutions dropwdown menu are tightly tied to mouse events. Moreover, the lack of a delay in the appearance and disappearance of the menu will cause a lot of trouble for people with poor eyesight or physical disabilities (for example, Parkinson's disease) - you can move the fig to the desired point. Here you have accessibility.
Reverse example: a developer spends a lot of time trying to make a clever web 2.0 application perfect from the point of view of semantics, not realizing that for people with disabled CSS or JavaScript it will never be of any use in view of its specifics, but to search engines access to indexing is closed because pages are accessible only to registered users.
Another example: HTML / CSS validation. By itself, the validity according to a certain Doctype does not bring any benefit to the project, does not make it more accessible and semantic, and does not say anything at all about the quality of the layout. It's just a tool, and they need to be able to use, not blindly obey. Say, I personally bring my projects into conformity with XHTML 1.0 Strict, but not because it is cool, elevates me over other developers and gives a good reason for criticism, but simply because I personally feel so comfortable for certain reasons (but Van Sagalayev does not like this option and he is also absolutely right). Unfortunately, very often I observe the opposite. By the way: an article on this topic .
Get into the essence 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 requirement, you don’t have to do it by holding your teeth together and swearing. Spend time explaining 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 you, the customer, or the project. Be above it. Look first at yourself, and then at others. In this case, it means, first of all, to think about what was wrong in your argument and how it can be made more convincing. Even if he, after listening to your arguments, decides to act in his own way, he will do this with an awareness of all the consequences, and besides, trust and respect for you as a specialist will increase - in either case , both parties benefit .
In the case of layout, the same applies to designers. A good designer should know both the difficulties in the layout of certain things and the possibilities of the Web that he can use. Therefore, when you as a typesetter, you actively interact with designers, and not just make up what you draw, you both grow professionally, and the project with you ultimately wins.
A person can achieve truly meaningful results only in those cases that he really loves, whom he is passionate about and deals with wholeheartedly. Look in your work for things that really fascinate, and do them no matter what . If you really want to write ultra-semantic code down 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 for it anyway. Loss of enthusiasm ultimately means loss of skills. Availability - continuous self-improvement and great results.
Thanks for attention. :)
update: pass the baton with the expansion of the subject (this one has already become boring a little) - abstractioneer 'at 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, in the event of the next bug in a particular browser, I want to solve the problem as soon as possible and this possibility appears. The most trivial example: a block shifts by a few pixels in IE, because you can move it back in the style for IE (or hack) and not bother. The desire is quite natural - the deadlines, as always, are tight, the result at the end is the same, and thank you for the extra effort you wouldn’t say - 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 efficiency in all subsequent projects. Moreover, such an attitude hampers your professional development in this area, which is much more important in the long term than the result of the current project.
')
If we postpone the result and take the time to really figure out why this is exactly what happened, in what other cases this bug appears, what ways are there to solve it (all, not one), in hundreds of similar situations this bug will continue ( in all its manifestations, and not only 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 solved instantly. With experience with this approach, you begin to write code that immediately works in all browsers, practically on the machine, without thinking - ask your friends gurus, they will confirm.
The same goes for decision making. Do not blindly copy a piece of code after you find a solution to Google - take a couple of minutes to find and explain why this works.
And yet - all this does not mean that you will have to break deadlines for the sake of professional development. Just learn how to take this time into account when agreeing terms 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 are perfect and those where they are not suitable at all. If you are just an amateur, you can stay on what suits you. But if you are a professional, you should know and be able to apply them all .
If in solving a specific task (for example, image replacement or multi-column layout) you are satisfied with one particular method - do not stop on it. Keep trying others. Read new blogs and use them too. You will gain valuable experience and gain flexibility in your business. And flexibility — the ability to adapt to changing conditions — is an extremely important professional quality that will ultimately gain you a lot of time.
In particular, by the way, this concerns the choice of a JavaScript framework. On this occasion, holivars are making amateurs - 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. (Another thing worth noting apart from the board is that it is much more important to understand the programming language JavaScript itself — specifically, it is much more powerful and interesting than it seems at first glance.)
3. Do not obey tools. Use them.
Take for example web standards and semantics. These are not unbreakable commandments; they are tools created for specific purposes. If you are obsessed with them only because your colleagues are telling you about this - if you don’t understand thoroughly why, what and in what case you need to comply - you will not be able to put them right in practice.
For example, a person made multi-level CSS-only drop-down menus and praises that it made the menu accessible (accessible) - now people with javascript disabled and users of screen reader 's can use it. At the same time, he does not realize that, despite the common myth, screen readers are fully supported by JavaScript and also react to CSS in certain cases (for example, many of them do not see the elements hidden using “display: none”), and that this solution cannot be used as users of screen readers, as well as all other people who navigate not using the mouse (for example, only from the keyboard) - all CSS-only solutions dropwdown menu are tightly tied to mouse events. Moreover, the lack of a delay in the appearance and disappearance of the menu will cause a lot of trouble for people with poor eyesight or physical disabilities (for example, Parkinson's disease) - you can move the fig to the desired point. Here you have accessibility.
Reverse example: a developer spends a lot of time trying to make a clever web 2.0 application perfect from the point of view of semantics, not realizing that for people with disabled CSS or JavaScript it will never be of any use in view of its specifics, but to search engines access to indexing is closed because pages are accessible only to registered users.
Another example: HTML / CSS validation. By itself, the validity according to a certain Doctype does not bring any benefit to the project, does not make it more accessible and semantic, and does not say anything at all about the quality of the layout. It's just a tool, and they need to be able to use, not blindly obey. Say, I personally bring my projects into conformity with XHTML 1.0 Strict, but not because it is cool, elevates me over other developers and gives a good reason for criticism, but simply because I personally feel so comfortable for certain reasons (but Van Sagalayev does not like this option and he is also absolutely right). Unfortunately, very often I observe the opposite. By the way: an article on this topic .
Get into the essence 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 the people with whom you work.
If your customer (or boss, or manager) makes a completely stupid requirement, you don’t have to do it by holding your teeth together and swearing. Spend time explaining 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 you, the customer, or the project. Be above it. Look first at yourself, and then at others. In this case, it means, first of all, to think about what was wrong in your argument and how it can be made more convincing. Even if he, after listening to your arguments, decides to act in his own way, he will do this with an awareness of all the consequences, and besides, trust and respect for you as a specialist will increase - in either case , both parties benefit .
In the case of layout, the same applies to designers. A good designer should know both the difficulties in the layout of certain things and the possibilities of the Web that he can use. Therefore, when you as a typesetter, you actively interact with designers, and not just make up what you draw, you both grow professionally, and the project with you ultimately wins.
5. Learn how to find more good in the selected case and focus on it.
A person can achieve truly meaningful results only in those cases that he really loves, whom he is passionate about and deals with wholeheartedly. Look in your work for things that really fascinate, and do them no matter what . If you really want to write ultra-semantic code down 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 for it anyway. Loss of enthusiasm ultimately means loss of skills. Availability - continuous self-improvement and great results.
Thanks for attention. :)
update: pass the baton with the expansion of the subject (this one has already become boring a little) - abstractioneer 'at five tips on Ruby / Rails, dobrych - on Python / Django, ld100 - on project management.
Source: https://habr.com/ru/post/26225/
All Articles