51–60 of 125 posts
I also have 10 years experience but I am in the same job because I can't defeat recruitment agencies. If today a new Framework, let's call it "Framework9" is announced, all jobs will instantly want 3 years experience, and 4-5 years experience of all other known frameworks, preferably in all languages, and preferably a designer who is a master of photoshop and CSS, with a long history of blah blah blah blah I am reall…
Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others made that we may find useful?
Not complaining about the article, but here are my thoughts. Write and maintain your own code for a significant amount of time. When you see bugs repeating themselves you have no one to blame but yourself. If you come back to code that you have written a few months later and you can't make sense of it fairly quickly, its probably time to refactor that part. Think about the design up front and the implications of doin…
My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. What makes you a better programmer is your ability to adapt and customize your approach to differen…
It's tough to say. Given a choice between being a JS ninja capable of hammering out http://www.track-trump.com/ in a week, or a generalist with a wide variety of skills, the former is so much more valuable from a monetary standpoint that it'd be hard to turn it down.
It's less satisfying, and you end up less capable in certain respects, but it all depends which axis you want to optimize along.
My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. What makes you a better programmer is your ability to adapt and customize your approach to differen…
- you can recover a little from all this learning. Your brain need rest too.
- you are really productive and hence are the best professional you can be.
Otherwise you spend your time eternally on project when you are not an expert at, which for your client/employer is not really fair.
Ok I came in thinking this was going to be another "don't do this, don't do that" type of deal, but was pleasantly surprised about it being upbeat and closer to e-prime. Nice job.
TIL: e-prime. Thanks. https://en.wikipedia.org/wiki/E-Prime
It was especially fascinating because the first sentence was something like "E-Prime refers to a version of the English language..." instead of "E-Prime is a version...". The article had all sorts of interesting quirks that really highlighted the diffs.
There's a lot of value here, but I have to raise concerns about a few things. First, the title: written in the past tense makes it seem like he believes the journey is complete. The article itself doesn't convey that message, fortunately. But I think it's worth noting that a critical skill for a professional is constant education - don't be satisfied that you're already "better", get better every day. I also strongly…
How should he have formulated the title then? I think it is logically correct.
Earlier quoted context omitted.
Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!
The time to clean up the code is when it already does what it should. That is: Make it pretty and readable and DRY once the code works. Until then my code can have several ugly and improvised things I've left for later.
I'm a bit skeptical of that as a general principle.
I want code to be a consistent representation of my mental model of the solution at all times. I use code to help me think, remind me of my thinking and communicate with others. It's not just a series of commands that make a machine do something.
As long as any ugliness is not in conflict with this purpose it's fine. I can totally live with functions that are a bit messy and probably need cleaning up later.
My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. What makes you a better programmer is your ability to adapt and customize your approach to differen…
> I usually stay 6 months to 1.5 years each on average
That's right around the point where you can increase your scope and responsibility within the team.
On the medium-large sized projects I work on you won't be making any major changes until the 12-18month mark.
Id say it's a good strategy for a junior dev but very limiting in the long term.