3 ms·

I would say if an web developer does not follow updates for 3 months he/she is a bit outdated, in 6 months out of web development and you try to make an comeba

I would say if an web developer does not follow updates for 3 months he/she is a bit outdated, in 6 months out of web development and you try to make an comeback you will find it very difficult to catch up. 1year or more out there are entirly new stacks, new libraries, new versions, new ways of building things etc. It not necessary to keep writing stuff following trends you just have to follow updates, newsletters, articles, so you dont struggle when you reenter the market.

jevgeni 9y ago
Thank you! My very subjective hypothesis was that it takes ca. 6 months to get "knocked out". For example I use ES and TypeScript only ocassionaly, and every time I have to do that, I have to rediscover conventions and practices that the community has developed in the meantime. At first it drove me nuts.
chuck32 9y ago
Sorry, this is really bad advice IMO. "1year or more out there are entirly new stacks, new libraries, new versions, new ways of building things etc." You think there are any dev teams which change their entire stack every year? As for new libraries, thats what documentation is for, nobody gets hired because they have a the newest & hottest libraries APIs memorized. Being a good developer has very little to do with knowing all of the trendiest new tools. A sound understanding of software engineering practices and methodologies is far more important.
- spcelzrd 9y ago
  In addition to having a sound understanding of software engineering practices, a good developer will be able to learn new tools, languages, and libraries. Being adaptable is a must. There's no reason to place a lot of value on a person who has already learned a particular library when you know they will eventually have to learn something else. Value the engineer underneath the layer of buzzwords.
  - jevgeni 9y ago
    You are right. I think fundamental knowledge is important in this case, where it allows you to cut throught the fluff of buzzwords and see what the actual content is.
- jevgeni 9y ago
  Well, this is bad advice only in a certain context. If an organization has reached a more mature period of your products life cycle, you are not concerned that much with new hot things that come out. If you need to generate product ideas and prototypes, or the all too familiar "productive prototype", then you are of course interested in stuff that will help you bring out new features cheaper and quicker.

jevgeni 9y ago

Thank you! My very subjective hypothesis was that it takes ca. 6 months to get "knocked out". For example I use ES and TypeScript only ocassionaly, and every time I have to do that, I have to rediscover conventions and practices that the community has developed in the meantime. At first it drove me nuts.

chuck32 9y ago

Sorry, this is really bad advice IMO. "1year or more out there are entirly new stacks, new libraries, new versions, new ways of building things etc." You think there are any dev teams which change their entire stack every year? As for new libraries, thats what documentation is for, nobody gets hired because they have a the newest & hottest libraries APIs memorized. Being a good developer has very little to do with knowing all of the trendiest new tools. A sound understanding of software engineering practices and methodologies is far more important.

spcelzrd 9y ago
In addition to having a sound understanding of software engineering practices, a good developer will be able to learn new tools, languages, and libraries. Being adaptable is a must. There's no reason to place a lot of value on a person who has already learned a particular library when you know they will eventually have to learn something else. Value the engineer underneath the layer of buzzwords.
- jevgeni 9y ago
  You are right. I think fundamental knowledge is important in this case, where it allows you to cut throught the fluff of buzzwords and see what the actual content is.
jevgeni 9y ago
Well, this is bad advice only in a certain context. If an organization has reached a more mature period of your products life cycle, you are not concerned that much with new hot things that come out. If you need to generate product ideas and prototypes, or the all too familiar "productive prototype", then you are of course interested in stuff that will help you bring out new features cheaper and quicker.