What are some tactics you can use as a junior/intermediate developer in a company with a lack of senior developers to mitigate the risks you discussed and foster growth?
My mother has a doctorate in social work, they have an idea in her field of "Critical Reflexivity". The idea being that theory and frameworks are vitally important to learn, but at the end of the day every case and every practitioner is different. To be a great social worker, it is not enough to learn theory and apply it, that is just the starting point. What you need to do is apply theory, but reflect at every step of the way on how it is working. This lets you build your own theory of practice, tailored to the way you work with people, and to the sort of people you work with day to day.
That resonated with me quite a bit, I feel like what she described to me is something all great developers I know do instinctually. I think at the end of the day, that constant honest reflection is the single most important thing to do for us. Our profession loves to pull ideas from math and other hard sciences, but at least from my part of it (product/business development), I think we can learn just as much from social sciences, if not more.
So what does that mean to a developer? When you see a problem somewhere, don't just stop at identifying it, try to classify it. What other problems are like it? Why did it happen in the first place? Read a lot of books about how to build software, but when you implement things from those books, try to reflect on the idea behind the solution, not just the solution. When it is done, reflect on how it worked out, and how the code looks at the end, what you like and what you don't like. If you go back to it, try to remember your initial feelings, and see how it panned out.
One big one: talk with marketing and sales about marketing and sales things. It helps you look into engineering from the outside, and see the other side of the interface - it shows you the pain of missed deadlines, and the surprising benefit of having that one extra feature. It helps you put real value to the output, and gives you context for measuring the worth of things you're spending time on.
Excellent answer. I think the real difference between a junior and a senior is not so much in coding skill; some juniors are really brilliant coders and can fix any problem you throw at them.
But a senior has more experience with the "why" behind the coding. What are the requirements in terms of schedule, user experience, stability, maintainability, performance, development process, QA, etc. A junior can be great at one of these, but a senior has to take responsibility for all of them. So you need to understand the needs of all the stakeholders outside the dev team. (At least the basics; functional details deserve an expert of their own.)
I think his point about over and under engineering stuff is spot on. I did both earlier in my career, and I would say that my skill after 12 years is in knowing the correct level of abstraction, and understanding the tradeoffs between various solutions.
(Yet all the interviews I turn up to these days want an hour and a half timed coding challenge to be completed).
I totally agree with you (and the article) on experience concerning the right level of abstraction. I don't think there's a quick shortcut to learning that, though.
I think an interview that focuses on coding challenges isn't really looking for a senior. Point them to a junior that's more appropriate to their needs.
In most interviews I do, we do talk about abstractions and maintainability and stuff like that. Although I have recently done one that involved a coding kata, which was kind of interesting because during the kata we also moved through a couple of (small scale) levels of abstraction while discussing them, and particularly the appropriate time to abstract some stuff.
Thanks. That is helpful. I have a tendency shared by the engineering department here to think we are separate from the rest of the business. We are in a separate building so it is hard to interact with any one but an engineer here.
One of parts of the article I liked best was the idea that we are developing solutions not code, and coding just happens to be a tool we deploy often not the job.
That resonated with me quite a bit, I feel like what she described to me is something all great developers I know do instinctually. I think at the end of the day, that constant honest reflection is the single most important thing to do for us. Our profession loves to pull ideas from math and other hard sciences, but at least from my part of it (product/business development), I think we can learn just as much from social sciences, if not more.
So what does that mean to a developer? When you see a problem somewhere, don't just stop at identifying it, try to classify it. What other problems are like it? Why did it happen in the first place? Read a lot of books about how to build software, but when you implement things from those books, try to reflect on the idea behind the solution, not just the solution. When it is done, reflect on how it worked out, and how the code looks at the end, what you like and what you don't like. If you go back to it, try to remember your initial feelings, and see how it panned out.