> senior engineer > been a professional engineer for 6 years Man, the software world is just weird.
Yeah, I stopped reading after this line. Sorry, but if you call yourself "senior" with 6 years of experience you've lost all credibility in my book.
What I learned working with a senior engineer as a new grad
31–40 of 199 posts
Re: What I learned working with a senior engineer as a new grad
#32Earlier quoted context omitted.
Easy to be a senior frontend engineer. Just say you were already around when the current most hyped JS framework was released that everyone must move to, 1-2 years ago.
You mean like React (9 years ago), Angular (12 years ago) or Vue (8 years ago)? Who seriously uses anything else? I think you confused the JS ecosystem with the C# one.
>I think you confused the JS ecosystem with the C# one.
What do you mean?
Re: What I learned working with a senior engineer as a new grad
#33Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.
The point is to always name your variables / methods / classes as exactly what they do (not how they do it, but what they achieve). If this name looks ridiculous, like `doXAndYAndZAndSideEffect`, then your code is likely poorly factored. I've found it works very well for helping to find good separation of concerns.
Re: What I learned working with a senior engineer as a new grad
#34I have never given much attention to functional programming just out of prejudice.
Now I read this blog and my head just exploded in the functional part.
It's beautiful.
What good introductions to functional can you people point me to?
Also, good code is like prose. You write to other to read, and you need to guide their minds.
Of course you can write in dense, truncated and clever ways, but your audience will be small (even yourself won't like your own prose 6 months from now).
Good software is delightful to read.
Re: What I learned working with a senior engineer as a new grad
#35Earlier quoted context omitted.
Easy to be a senior frontend engineer. Just say you were already around when the current most hyped JS framework was released that everyone must move to, 1-2 years ago.
You mean like React (9 years ago), Angular (12 years ago) or Vue (8 years ago)? Who seriously uses anything else? I think you confused the JS ecosystem with the C# one.
Angular will turn 6 years old next month. You're thinking of AngularJS, which despite the (unfortunately) similar name and parent, is basically a completely different framework.
Although I don't see why you're bashing C#. Despite the .NET Framework > .NET Core > .NET transitions, it's not really that different. There's a ton of new functionality and ways to do things, but for the most part the old ways still work too.
Re: What I learned working with a senior engineer as a new grad
#36Earlier quoted context omitted.
And a PhD would be senior to a graduate? Also the quote is 'professional', so although it's probably not the case, it doesn't preclude spending your 6 years in 'graduate school' beforehand anyway.
After PhD, people are forced to do postdocs, which are nominally junior positions.
But not compared to the new grad/undergraduate intern washing petri dishes or whatever. My point is that what you label 'junior' doesn't matter, it's all relative.
Re: What I learned working with a senior engineer as a new grad
#37> senior engineer > been a professional engineer for 6 years Man, the software world is just weird.
Yeah, I stopped reading after this line. Sorry, but if you call yourself "senior" with 6 years of experience you've lost all credibility in my book.
The author said that, we don't know if the mentioned person does it.
Re: What I learned working with a senior engineer as a new grad
#38Clean code is code you and others can understand and everybody seems to have a different idea of that. Sentence long variable names I don't like, they slow me down when thinking about or remembering what to do I'm not sure you can remember the names without Intellisense/IntelliJ autocomplete. I don't think I would enjoy working on this codebase.
The recommendation I read back in the 90's in Code Complete that has served me well ever since was that variable name length should be roughly proportional to the variable span. "Variable span" being the distance between where the variable is first defined and its last use. Generally that means that a temp variable inside a short function can be a single letter since you can see the full context of its entire lifecycle right there and it's unlikely to be confusing; indeed, a short variable name in that case will often be much easier to read and work with than a longer one. OTOH, a global or exported variable that might be accessed in different files from where it is defined or used across thousands of lines really needs to be descriptive enough that anyone encountering it should know what it's for without having to backtrack to where it was defined. A variable name that's a few words long might be entirely appropriate for that. A corollary is that a large variable span is often an indicator of a bad design. So if you find that you need really long variable names to make your code easy to understand, you might want to step back and see if you could set up some better or different boundaries.
I've found this to be a much better rule of thumb than "always use long variable names" or "always use short variable names".
Re: What I learned working with a senior engineer as a new grad
#39I have never given much attention to functional programming just out of prejudice. Now I read this blog and my head just exploded in the functional part. It's beautiful. What good introductions to functional can you people point me to? Also, good code is like prose. You write to other to read, and you need to guide their minds. Of course you can write in dense, truncated and clever ways, but your audience will be sma…
What part are you referring to? I don't see any FP stuff in that article... It's all imperative code?
Anyway I would recommend learning Haskell. I like languages that allow different styles (like js does to a certain extent). But I think it's better to learn a modtly pure OO language like java and a pure FP language like Haskell to be able to make the right decisions in a language that supports both like JS.
Re: What I learned working with a senior engineer as a new grad
#40Earlier quoted context omitted.
For software developers, I've thought 5 years of solid work and continuous learning is about the right time horizon for a senior title, in a typical contemporary software/internet company. (At least, 5 years of seeing the lifecycle through awhile -- not job-hopping repeatedly, before getting to see cause and effect together.) I could even see that going faster than 5 years, especially in a startup. For example, say o…
I absolutely cannot agree with this. It's true that after five years in a startup, you'll have seen lots of systems. But being a senior practitioner requires deep experience as well as breadth, and enough time in the industry to recognise larger trends. There is no magic mark for this, and it's quite possible to reach ten years and still be a weak practitioner, because you were exposed to a narrow range of problems a…
Good point about the increasing demands on Seniors in some regards. (The role might also be changing, such as juggling lots of high-level abstractions and vendor bureaucracy in many domains, with a significant amount of Stackoverflow consultation, rather than lots of experience in lower-level details.)
I'm trying to reconcile meaningful titles with current industry norms.
I'm open to other schemes, but, FWIW, this is my current rough idea:
* First is some kind of new college grad. Some of whom would object to Junior in their title, and I think Technician sends the wrong message about near-term goals, so I'd just call it plain Software Engineer.
* After maybe at 1 or 2 years, they've been through some projects, and they know a lot of the mechanics (big contrast to a new-grad who learns as they unlearn what they got from bloggers). You want to acknowledge that, so maybe it's Software Engineer II.
* At some point, maybe it's 5 great years in, they've seen a lot of stuff, and gotten wisdom and insight, and Senior sounds about right and conventional. This could be a plateau title that someone has for a decade, even as their TC increases quite a bit.
* Staff and Principal engineer roles transcend project teams (more than Seniors do). Large companies will each have their own definitions, and there might also be unwritten meaning. (At my first hardcore software engineering employer, there was no Staff, and only a tiny percentage ever made Principal. By the time I made Senior, the VP asked me where I saw myself in 5 years, and I said Principal... He gently set expectations that that's pretty ambitious, only a few people ever do it, and 5 years would be very fast. Correct on all points, and now I think I have a better idea of how much more the Principals knew that I didn't even know were things to be learned.)