A while back, I wrote about the stages of your software development career where I laid out a simple way to think about the general steps that most...
For further actions, you may consider blocking this person and/or reporting abuse
$.02 - If someone wants to be a "senior developer" they should pursue goals as described in this article and measure themselves by achievement of those goals.
Don't measure yourself or others by a job title. In many places everyone has the title of Senior Developer or higher. It means a) they've worked there for a few years or b) when they were hired they negotiated for a higher title.
It's pervasive and unlikely to change. We just need to be aware of it. It's usually harmless, but in some cases a newer developer (I never use the term "junior" because we're all adults) can have his or her growth stunted by following the examples of senior developers who stopped learning years ago right after they figured out how to throw together really bad code. They're called expert beginners. It's a lot easier to avoid becoming one if you realize that the phenomenon exists.
💯 I was there and had to do exactly this - learn on my own and set my own expectations with where I wanted to go in my career.
A good rule of thumb is to look up to people who have already achieved what you want (which shouldn't be simply the title of "senior developer").
Want to be a competent senior dev? Look in the broader community for people who are considered great seniors devs.
It's true, there are SO many developers who stay with the same company doing, mostly, the same stuff and are given new titles just because they've been there for X years.
Erik Dietrich (@daedtech ) has written about this phenomenon while identifying a career-path 'black hole' of the "expert beginner": daedtech.com/how-developers-stop-l...
Sweet - thanks for the link! I read this one in a galaxy long ago but will be re-reading. Erik's stuff is gold 👍
Thanks for the mention!
I total agree. Great Article!
One thing I think you are missing. I'm sure you thought this was obvious but I want to point it out. A senior developer creates quality software consistently. Your not a senior developer if your code always has problems.
Depth and Breadth is key in my opinion also.
Thanks Kyle! I would agree, there should be high degree of quality software being produced. You can be senior in title, yet not in actual competency.
As others have noted, that is VERY common in our industry (and in other industries too I'm sure 😋)
"Their life is not as erratic, spontaneous and experimental"
Ouch :-(
😂 Some people seem to have issues with this statement, which is only a metaphor after-all lol.
But, it's true... if you've gained meaningful experience and have had the chance to experiment then shouldn't you have learned from those experiences?
Shouldn't you be able to approach solving problems in a less spontaneous way?
And way up the scale, shouldn't we be learning about (mental) systems that help us to manage problem-solving so we aren't just throwing random ideas at problems?
I get your point but let me say this: you develop a framework for problem solving as you advance in your career, which can sometimes constrain you. But that's why you have to keep being open to experimentation. That's how you actually grow and improve. Otherwise you can easily fall into the "use the hammer for everything" problem…
Def. 💯 But that idea itself (let's get meta...) is part of a problem-solving framework itself 😜.
I agree that a very rigid way of solving problems everywhere is def. going to constrain you 100%.
But even in times of experimentation, your experience should guide you in knowing:
So even the process of experimentation itself has some over-arching framework that you implicitly and explicitly are aware of - which, in the end, should be informed and improved by your past experience.
That's a bit more philosophical than most would like 😂.
James, very comprehensive. What's your view on visual-based (data-modeling) programming tools? 'Low-code' as Forrester calls it.
Thanks! Visual data-modelling is fine as long as it's restricted to database models (I find). They are helpful to build out your tables, relationships, etc. fast and get a handle on the overall structure.
However, what I find is that a more "code first" approach is, in the long run, a way better and maintainable way to approach building software.
This would be more in-line with a Domain Driven approach. Your data doesn't drive your code, but your code (with very rich domain models) drives your data storage/models.
I think it was Martin Fowler who once talked about working on a project where they literally ignored the database for a project, building all the code and focusing on modelling the business domain well. For the time being, they just stored everything in memory (or perhaps just to a plain binary file...something like that).
Only at the end of the project did they "plug in" a real storage mechanism.
I think that type of approach is best. And I don't think visual modelling works that well with building out code architecture, classes, etc. (although perhaps there are some tools that DO work well? Just as long as you aren't focusing on data, but on modelling the business domain ala Domain Driven Design, etc.)
Thanks for the insight James. Forrester Research shows low-code platforms growing by 50% year on year at present. outsystems.com/ and mendix.com/ are current market leaders. Outsystems developers seem to like it a lot. Do you think that's because they're... not very good developers and use it as a crutch or perhaps it actually makes a bunch of things easier, so they can focus on the more creative / challenging parts that require new coding?
If I took Ionic Studio as an example (since I'm currently leading a project building an app using ionic) - this is great.
It's great to work with the UI and build it out fast.
That being said, (I've never used ionic studio), there's probably a lot of manual tweaking that needs to be done to the generated UI code.
Now, when we talk about non-UI stuff like making API requests, auth logic, caching mechanism, network detection, etc. I would think that's best handled best manually.
I personally see lots of value in building UIs like this, but when it comes to the code that is generated....well, I don't expect it to be that "great". And even if it is, there will still be lots of other non-UI stuff to get done.
So, can a dev team use one of these tools? Sure! But like you said, if used by entry-level devs...should we expect a performant and maintainable product in the end?
These do look like great tools for building (probably) more simple straightforward apps. And there's a place for that, sure. But the trade-off is that any complex logic that is needed by the app, or perhaps unconventional experiences probably won't fit.
Especially for mobile apps, that are usually more simplistic than, lets say, a web app, I have no real big issue in general.
But you'll still an API on the back-end to hook into to do all the "heavy lifting".
Thank you so much. So interesting!
Nice article.
Thanks!