21 ms·

Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you r

by beat 7y ago

Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read. Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most. Learned as junior: New tech solves old problems. Understood as senior: New tech creates new problems.

agumonkey 7y ago
> Understood as senior: Communication skills matter most. can you give examples ?
- halfmatthalfcat 7y ago
  Articulating requirements or architecture to either stakeholders or juniors is key to being able to actually do your job as a senior (whether that's coding yourself, code reviews, planning, interviews, etc etc).
- Kalium 7y ago
  I once worked with a brilliant engineer. He was from Hong Kong. He struggled to express his ideas in English. We tended to let him show us in code instead. Sometimes this worked. Sometimes it really, really didn't. It also meant we had a very difficult time discussing larger architectural questions with him or giving him useful feedback on his code.
  - agumonkey 7y ago
    Well that's half cultural, I meant in a context of shared native tongue. Now international work does create lots of hurdles because you can't translate things above casual smalltalk. I guess that's where maths could help.
  - ben_w 7y ago
    I’ve recently had a similar problem, only in my case I’m the foreigner who can’t speak the local language. It’s fine except in meetings. Junior dev me: meetings are a waste of time. Senior dev me: meetings are the steering wheel, the developers are the engine (https://kitsunesoftware.wordpress.com/2018/01/29/utility-function-of-meetings/ https://kitsunesoftware.wordpress.com/2018/01/29/utility-fun...)
- deleted 7y ago
  [deleted]
- dahart 7y ago
  I can try. Teaching juniors can be more productive than coding. Being 10x by yourself is less good than 3x-ing a whole team. Even better, teach everyone to be as fast & good as you. Good teaching requires good communication and building trust. Understanding priorities and goals is absolutely critical to making good choices while programming. Writing good code under reasonable deadlines in an organization necessarily involves a lot of discussion about what constitutes an acceptable solution, what doesn’t, how long it might take, how long is too long, what features are nice but not necessary. Over-engineering, for example, is extremely common, and is caused in part by not correctly balancing goals and priorities with time budgets. It’s usually a symptom of mis-communication. Can’t even count how many times I’ve seen a programmer go off the rails building stuff that wasn’t asked for, only to have a meeting several weeks later that invalidated weeks of work when the goals were clarified. (That includes me, btw.) Making large changes and leading a group of programmers often requires a lot of convincing and rallying work along with the technical planning, sometimes much more than you’d expect. It also requires the ability to put yourself aside and allow others to contribute to the design, even when you think your technical solution is superior. Getting promoted is, in my experience, most commonly a process of demonstrating to others that you listen well, organize well, work well with others, get things done under deadlines, understand and report what juniors are doing to management, budget well, internalize the organizational goals and contribute meaningfully to meeting those goals. In short, it’s because teamwork is important.
  - agumonkey 7y ago
    Alright, I just failed to parse what communication could mean. I see it clearly now, leadership, team work, social skills, they do indeed matter a ton.
- deleted 7y ago
  [deleted]
- fendy3002 7y ago
  It's mainly used when discussing task and making architectural / design decision. Junior usually talk in techincal / implementation terms. While senior usually talk in broader / general / business term. Moreover junior usually have hard time expressing techincal problem.
- yxhuvud 7y ago
  If nothing else, it is a godsend when talking to PMs. A junior may be like "this code sucks, it is too complex!!" where a more senior can be more like "This code is not written in a good way. If we had some time to rewrite these particular parts, we could provide these features to the users". Being able to couple value to what you do, or for that matter, to what might not be worth pursuing, is a very good skill. And be sure to not often say no to a PM asking for a feature, but rather give an alternative "doing that is quite complex and might take us half a year. How about we do this other thing that gets us 90% of the way there, but only take a week to implement?"
- slezakattack 7y ago
  There's no hard-and-fast rule on this but generally junior projects are isolated where you may only have one stakeholder. Growing into a more senior role, your actions generally have greater breadth that affect more teams/clients/orgs. Technical chops are worthy but I can guarantee that your stakeholders would rather have amazing communication for things like progress, deployment, etc. than how efficient or beautifully written the project is.
dahart 7y ago
Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” My goals used to be to write code that looked and felt cool to myself and others, to add features in clever ways with as little change to the function signatures and structure as possible so as to not disturb the architecture. While keeping changes small is a good goal to balance, it’s always possible to be too small and add unnamed concepts and fail to restructure around new concepts when you should. Do that a few times in a row (which I have done) and you end up with architectural spaghetti code that might look clean and modular at first glance but becomes a maintenance nightmare. My goals are now to: - make code so easy to read it’s boring, because if it looks interesting, it’s probably too clever - and to identify and name all the unnamed concepts and refactor often to accommodate new features.
- RussianCow 7y ago
  > Sometimes I don’t even recognize me as the author for a while. This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)
  - gmueckl 7y ago
    This is why I will point out issues in code only on the form of stating potential improvements as best as I can. I especially try to avoid hating on the author - it might have been me or the boss who's standing nearby... In fact, I often conciously refrain from using blame on an "interesting" piece of code because it doesn't matter who wrote it. Looking it up would just satisfy idle curiosity, but yield noninsight into how to improve the code. In fact, I think that blame should just list the commits, but hide the authors by default. "What changed? " and "how?" are always much more pressing questions than "who?".
leibnitz27 7y ago
Way back in the day, my boss made a lovely observation - 'write your code like it's going to be maintained by an axe murderer who has your home address, and nothing to lose.' Simple guidelines to live your life by ;)
- kps 7y ago
  Attribution: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John F Woods, 1991 in comp.lang.c++¹ (I do not know who first replied, ‘I do know where I live.’) ¹ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4lXw/oITtSkZOtoUJ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...
- forgone 7y ago
  Did he call it "his" observation? I am yet to find a likeable person quoting this.
GordonS 7y ago
> Understood as senior: Legacy code that I wrote myself is hard to read. Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!
- dotnetdemon 7y ago
  I always find myself saying “Who is the shithead who wrote... oh...”
  - mosdl 7y ago
    Its a good sign - means you are learning and getting better.
docker_up 7y ago
> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.
- lmm 7y ago
  Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.
  - ZeroMinx 7y ago
    > Comments should be a last-resort stopgap I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.
  - dbingham 7y ago
    Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".
robomartin 7y ago
All excellent points. I got used to filling my code with comments in the spirit of having a conversation with someone to whom I am explaining how an why. Thirty years later I can look at any of my code and quickly understand it. In sharp contrast to this I find most open source code to be difficult and laborious to understand due to the almost total lack of useful comments.
JustSomeNobody 7y ago
> Learned as junior: New tech solves old problems. > Understood as senior: New tech creates new problems. This is one all the people who push "new and shiny" need to learn.
- giancarlostoro 7y ago
  I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. Or would you rather everyone stick to coding in VB6? I rather we all use C# instead of VB6 ;) I'm not implying we only ever use C#, I know there's other languages, just illustrating a shift in the MS windows development ecosystem that was for the better.
  - JustSomeNobody 7y ago
    > I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. I don't believe this is the spirit in which this was meant. If the old system is out of date and there are buggy libraries that aren't being maintained, that is a WHOLE different issue.
  - kerng 7y ago
    VB 6 is probably not a good example. Even nowadays many languages don't have features that VB6 offered incl. WYSIWYG. Debugging capabilities of modern languages/environments are still often not even close to what VB6 offered 20+ years ago. C# certainly is outstanding but I think Microsoft made a gigantic mistake by killing VB6 the way they did. Microsoft's prevented a large amount of people to write applications, since a new ecosystem like C# or VB.net was significantly more difficult to learn and understand. In retrospect Python or Node probably took VB6's place, so Microsoft just lost out on a huge market there. Bad management decision.
kps 7y ago
Lemma: > Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read. Lemma: > Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most. Theorem: Communication needs to target the people of the future.
- beat 7y ago
  Outstanding observation, thank you!
LordHumungous 7y ago
> If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Similarly, one thing I learned is that if I find a bug with an OS or platform, 9 times out of 10 it's actually due to some problem in my code or my own lack of understanding :)
- loco5niner 7y ago
  Can suggest it's more like 999 times out of 1000?
enobrev 7y ago
> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git reset --hard HEAD` or end up with a similar solution, but with better comments Once in a while, I end up with a [simpler | faster | clearer | otherwise better] version, which makes this process worth while - even with the false positives.
- sbmthakur 7y ago
  > Re-realize the edge-cases and difficulties I think comments can help avoid such scenarios.
- snicky 7y ago
  Semi-related story of mine: 1. Stumble upon some specific problem with a web framework we use. 2. Jump straight to stackoverflow. 3. Sbd had a similar issue, nice. 4. Sbd wrote a very concise answer, nice too. 5. There's my nickname under the answer. Oh, wait...
  - grogenaut 7y ago
    I'm getting the statement about once a quarter at work of: Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.
    - eitland 7y ago
      Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.
      - gambiting 7y ago
        I'm sad that I cannot share my experiences the same way :-( 99% of my "interesting" bugs are almost all Xbox One/PS4 related, so I can't write a blog post about "how I found out that Sony's implementation of file read is not compatible with regular stdio" - it's hugely interesting but this stuff is NDA'd to such an extent that I wouldn't risk writing openly about it - but I'd love to.
taneq 7y ago
> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.
- yakshaving_jgt 7y ago
  I wish my mother knew what a compiler was.
  - taneq 7y ago
    Heh, at 19 she was the PL/1 expert for the Asia/Pacific region. Mum's a badass.
- beat 7y ago
  One of the first rules from the book The Pragmatic Programmer is "SELECT isn't broken". (It might even be the first rule.)
kbenson 7y ago
> Understood as senior: Legacy code that I wrote myself is hard to read. As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then.
- toxik 7y ago
  I disagree with this perspective. You of yesteryear is in many ways just another programmer you have to work with; if that makes you cringe, you may be taking a bit too much pride in your work.
  - kbenson 7y ago
    > You of yesteryear is in many ways just another programmer you have to work with Taking that idea to the extreme of not having any feeling of ownership or pride (or lack thereof) in your past work seems rather silly to me. It wasn't just some other programmer, it was you. I'm not saying you should cringe because the code is bad, but because you should have a sense of "well, I could have saved myself some trouble or made this cleaner/more obvious if I only knew then what I know now."
    - Retra 7y ago
      Or maybe you cringe at your old 'good' code because you spent too much time on things that ultimately didn't matter.
- fendy3002 7y ago
  It isn't as simple as better skilled or not. Many times having more understanding about the problem may open your eyes to better / simpler design, or you now don't have any rushing matter that fuel bad design in the past.
- Scarblac 7y ago
  There are absolutely things I was better at back then, mostly because then I spent all my time doing nothing but programming and now a lot of time goes to other activities (meetings, planning, writing, etc).
alkonaut 7y ago
New tech solves your existing problems and creates new ones. I have a big pile of problems I have had for many years that I’d love to trade for some new ones. I’m happy to fix one problem and get 5 new ones. I’m happy to get rid of an easy problem and get a new much harder problem. The important thing is that I get some new problems, and nothing will do that like new tech.
Gibbon1 7y ago
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. Me: 'Even a blind squirrel finds a nut once in a while'
- cja23 7y ago
  Horses, not zebras. But yes, there are a few zebras in the world also.
  - Gibbon1 7y ago
    Depends on what they are doing. Oh you found a 'bug' in Mac OS, Windows, or Linux? Probably not. Oh you found a 'bug' some open source library? Maybe. Or in our in house developed framework? Probably. In house framework I wrote? Certain of that.
bpyne 7y ago
"Understood as senior: Legacy code that I wrote myself is hard to read." Your comment came at the perfect time. I just finished debugging a "high urgency" problem with a program I developed and maintained for the past 10 years. The program started simple with a small list of rules to apply against data sets. Over time the list became a tree of rules that expanded in both breadth and depth. It was refactored once to get the design in line with the rules of the time. The "high urgency" issue turned out to be the program working correctly. But, the functional user wasn't able to keep in mind some of the rules he set. It took me a half hour, with lots of "why did I do that", to explain it again to the user.
jshowa3 7y ago
Things I've learned: I'll never be a senior programmer.
justbaker 7y ago
>Understood as senior: Communication skills matter most. I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.
- kenhwang 7y ago
  There's also a strong correlation between strong communication skills and strong technical skills in our industry that demands frequent learning of new skills. So not only does strong communication augment technical skills, it also signals its strength which is also valuable to software developers.
chadash 7y ago
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell him that the data isn't ready because there's a bug in Excel. I was laughed at by the entire team. They agreed to give me $1000 right then and there if it was really a bug, but if not, I had to admit the shame. Well... of course it wasn't a bug in Excel, I just made a careless, albeit hard-to-find, mistake. Lesson learned. If millions of people use something, that doesn't mean it doesn't have bugs. But it does mean that you probably aren't going to find those bugs unless you are doing something strange. oddly, I did once find an actual bug with indexes in Postgres. Because of my earlier experience, I spent a lot of time assuming it was me before I finally isolated it as being a bug with postgres itself. I submitted a bug report and it was patched within a day. But still, 99% of the time, it's me.
- xmprt 7y ago
  You can't tease us like that without explaining what the "bug" in Excel was.
  - chadash 7y ago
    As I said, it wasn't a bug in the end :) The issue was with my formulas, but I don't recall exactly what I did wrong. It was a tiny typo I made a sheet with thousands of formulas if I remember correctly.
- beat 7y ago
  I actually found an OS bug in AIX on my first real I-designed-this code project. Worse, the bug was discovered only when the code went into production - it behaved differently on the test servers than on the production servers! The bug caused mmap() system calls to randomly overwrite certain pages in memory with NULLs. Yeah, that was fun. And it was caused by the order in which patches had been applied, which was why it behaved differently in production than in dev/test. If some second year programmer told me that nonsense, I'd make them go back and either find their bug, or write a test program that exercised the bug in isolation (which was what I did).
bunderbunder 7y ago
> Understood as senior: New tech creates new problems. Related: There are no new problems.
SkyMarshal 7y ago
>Learned as junior: Technical skills matter most. >Understood as senior: Communication skills matter most. I see this often, but it needs to be said with a caveat - the second line presupposes the first. Without the first, the second doesn't really matter (or it does but you're in the wrong career).
- retiredcoder 7y ago
  Actually it is very disfuncional for me to be in a company that communication skills are ahead of technical.
TheAceOfHearts 7y ago
Sometimes you encounter some questionable code and you wonder: "What idiot wrote this?" So you `git blame` and you find out "Oh, I'm that idiot."
- retiredcoder 7y ago
  I have been in this situation and tried to remember what was going on while I wrote the questionable code. It frequently came down to a day full of interruptions and context switching. Also motivation plays a tremendous role, I know that whenever I have to work on a code base I don’t understand and don’t want to have anything to do with it long term, it ruins my ability to focus.
whatever_dude 7y ago
> Understood as senior: Communication skills matter most. I've been of a similar opinion at some point, but now that I see people _optimizing for communication_ as juniors in lieu of actual technical skills, I say: both matter a ton. I hate dealing with a junior that is an extremely good people person but a terrible developer: they tend to think they got everything covered just because people like them so much, even when their actual solutions are terrible.
philwelch 7y ago
> Learned as junior: New tech solves old problems. > Understood as senior: New tech creates new problems. Yep! When you use "new tech", you're making a bet, and not all bets pay off. If you're cautious, you'll hold off until new tech is proven (or pilot it cautiously before migrating). If you're possessed with good judgment, you'll be discriminating in which new techs you adopt. If you have both virtues, you may even gain a competitive advantage.
bsder 7y ago
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. And, yet, it does happen. The important part as the senior guy is to make the junior guy create a test case and then cut it to the bone until it is obvious where the bug is. Story time: It's mid ninteen-ninety-mumble and your intrepid hero is a junior programmer handling multi-site integration and testing tool infrastructure. This being the time when the Swiss Army Chainsaw(tm) (aka Perl 4) is well and truly entrenched in the sysadmin and toolsmith programmers, my technical superiors throw me a couple of Perl books, set my deliverable date impossibly soon, and tell me to get going post haste. So, I code. It's not a lot of code, but it is parsing and matching files in 3 different formats from 3 different sites. Of course, I hear what you are saying: "Perl and parsing is like mixing ammonia and chlorine--and probably more painful." Yes, I concur. But, it is the tool at hand in the long forgotten mists of time when RAM was expensive and spinning rust still resembled an iron brick. So, off I go with regexes for parsing (Yes, I know, now I have 3 problems). And everything worked quite swimmingly. Except for a bit of idiocy that nobody could track down that occasionally flagged a couple of records as mismatched when manual inspection showed they really were not. Nobody minded that much as the scripts got 99.99% of the job done and didn't give a false negative, so: "Ship it, junior." And so we did. However, the bug annoyed me because I had to got clean up the false positives when they fired. And, if I am anything, I am a VERY lazy programmer--and this was preventing me from being lazy. So, I eventually am waiting for one of the other groups to deliver, and I go spelunking for a testcase. Spelunking? HAH! Cave diving is a better analogy. The program took the most inclusive of the syntaxes, used each record from that to build a regex to look for the corresponding record in the other syntaxes, matched what it could and flagged what remained. So, the program was building a dynamic regex on-the-fly and then using it. Not a huge deal, but the regexes were larger than most people were probably comfortable with. No problem, I validated this on much smaller records out to REALLY big records, and they work well. Except for those weird cases ... So, I'm looking through a case that works and trying to compare it to a case that doesn't. And I accidentally fat-finger some character set match and delete a character that shouldn't matter. And the regex fails ... provoking the Asimovean "That's funny ..." So I delete another character ... and it works again. What?!?!?! So, I add a character. And it fails. And I add another. And it works again. I stared at that regex for what felt like EONS until the light bulb went on. The one that worked? 511 characters or 513 characters. The one that failed? 512 characters. So, yes, I, a total Perl n00b managed to find a bug in Perl 4 in my first ever Perl program. Sometimes the junior dude gets really unlucky and finds an actual system-level bug.
jv22222 7y ago
> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you Same thing happens in reverse! ;) A few years back I told 3 devs who reported to me that there was a bug in Laravel database sub system. The bug was: If you use the word "returning" in any Laravel insert query the system would crash (Laravel 3 & 4). None of my guys would believe me! I finally tracked the bug down to > laravel/database/connection.php > public function query($sql, $bindings = array()) > { > ... etc ... > elseif (stripos($sql, 'insert') === 0 and stripos($sql, 'returning') !== false) I sent an email to the Laravel team and never got a response... but the bug stopped happening some time after that ;) I think it was relate to mySQL version as well.
deleted 7y ago
[deleted]

by beat 7y ago

agumonkey 7y ago

> Understood as senior: Communication skills matter most. can you give examples ?

halfmatthalfcat 7y ago
Articulating requirements or architecture to either stakeholders or juniors is key to being able to actually do your job as a senior (whether that's coding yourself, code reviews, planning, interviews, etc etc).
Kalium 7y ago
I once worked with a brilliant engineer. He was from Hong Kong. He struggled to express his ideas in English. We tended to let him show us in code instead. Sometimes this worked. Sometimes it really, really didn't. It also meant we had a very difficult time discussing larger architectural questions with him or giving him useful feedback on his code.
- agumonkey 7y ago
  Well that's half cultural, I meant in a context of shared native tongue. Now international work does create lots of hurdles because you can't translate things above casual smalltalk. I guess that's where maths could help.
- ben_w 7y ago
  I’ve recently had a similar problem, only in my case I’m the foreigner who can’t speak the local language. It’s fine except in meetings. Junior dev me: meetings are a waste of time. Senior dev me: meetings are the steering wheel, the developers are the engine (https://kitsunesoftware.wordpress.com/2018/01/29/utility-function-of-meetings/ https://kitsunesoftware.wordpress.com/2018/01/29/utility-fun...)
deleted 7y ago
[deleted]
dahart 7y ago
I can try. Teaching juniors can be more productive than coding. Being 10x by yourself is less good than 3x-ing a whole team. Even better, teach everyone to be as fast & good as you. Good teaching requires good communication and building trust. Understanding priorities and goals is absolutely critical to making good choices while programming. Writing good code under reasonable deadlines in an organization necessarily involves a lot of discussion about what constitutes an acceptable solution, what doesn’t, how long it might take, how long is too long, what features are nice but not necessary. Over-engineering, for example, is extremely common, and is caused in part by not correctly balancing goals and priorities with time budgets. It’s usually a symptom of mis-communication. Can’t even count how many times I’ve seen a programmer go off the rails building stuff that wasn’t asked for, only to have a meeting several weeks later that invalidated weeks of work when the goals were clarified. (That includes me, btw.) Making large changes and leading a group of programmers often requires a lot of convincing and rallying work along with the technical planning, sometimes much more than you’d expect. It also requires the ability to put yourself aside and allow others to contribute to the design, even when you think your technical solution is superior. Getting promoted is, in my experience, most commonly a process of demonstrating to others that you listen well, organize well, work well with others, get things done under deadlines, understand and report what juniors are doing to management, budget well, internalize the organizational goals and contribute meaningfully to meeting those goals. In short, it’s because teamwork is important.
- agumonkey 7y ago
  Alright, I just failed to parse what communication could mean. I see it clearly now, leadership, team work, social skills, they do indeed matter a ton.
deleted 7y ago
[deleted]
fendy3002 7y ago
It's mainly used when discussing task and making architectural / design decision. Junior usually talk in techincal / implementation terms. While senior usually talk in broader / general / business term. Moreover junior usually have hard time expressing techincal problem.
yxhuvud 7y ago
If nothing else, it is a godsend when talking to PMs. A junior may be like "this code sucks, it is too complex!!" where a more senior can be more like "This code is not written in a good way. If we had some time to rewrite these particular parts, we could provide these features to the users". Being able to couple value to what you do, or for that matter, to what might not be worth pursuing, is a very good skill. And be sure to not often say no to a PM asking for a feature, but rather give an alternative "doing that is quite complex and might take us half a year. How about we do this other thing that gets us 90% of the way there, but only take a week to implement?"
slezakattack 7y ago
There's no hard-and-fast rule on this but generally junior projects are isolated where you may only have one stakeholder. Growing into a more senior role, your actions generally have greater breadth that affect more teams/clients/orgs. Technical chops are worthy but I can guarantee that your stakeholders would rather have amazing communication for things like progress, deployment, etc. than how efficient or beautifully written the project is.

dahart 7y ago

Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” My goals used to be to write code that looked and felt cool to myself and others, to add features in clever ways with as little change to the function signatures and structure as possible so as to not disturb the architecture. While keeping changes small is a good goal to balance, it’s always possible to be too small and add unnamed concepts and fail to restructure around new concepts when you should. Do that a few times in a row (which I have done) and you end up with architectural spaghetti code that might look clean and modular at first glance but becomes a maintenance nightmare. My goals are now to: - make code so easy to read it’s boring, because if it looks interesting, it’s probably too clever - and to identify and name all the unnamed concepts and refactor often to accommodate new features.

RussianCow 7y ago
> Sometimes I don’t even recognize me as the author for a while. This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)
- gmueckl 7y ago
  This is why I will point out issues in code only on the form of stating potential improvements as best as I can. I especially try to avoid hating on the author - it might have been me or the boss who's standing nearby... In fact, I often conciously refrain from using blame on an "interesting" piece of code because it doesn't matter who wrote it. Looking it up would just satisfy idle curiosity, but yield noninsight into how to improve the code. In fact, I think that blame should just list the commits, but hide the authors by default. "What changed? " and "how?" are always much more pressing questions than "who?".

leibnitz27 7y ago

Way back in the day, my boss made a lovely observation - 'write your code like it's going to be maintained by an axe murderer who has your home address, and nothing to lose.' Simple guidelines to live your life by ;)

kps 7y ago
Attribution: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John F Woods, 1991 in comp.lang.c++¹ (I do not know who first replied, ‘I do know where I live.’) ¹ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4lXw/oITtSkZOtoUJ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...
forgone 7y ago
Did he call it "his" observation? I am yet to find a likeable person quoting this.

GordonS 7y ago

> Understood as senior: Legacy code that I wrote myself is hard to read. Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!

dotnetdemon 7y ago
I always find myself saying “Who is the shithead who wrote... oh...”
- mosdl 7y ago
  Its a good sign - means you are learning and getting better.

docker_up 7y ago

> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.

lmm 7y ago
Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.
- ZeroMinx 7y ago
  > Comments should be a last-resort stopgap I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.
- dbingham 7y ago
  Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld. If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it. And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".

robomartin 7y ago

All excellent points. I got used to filling my code with comments in the spirit of having a conversation with someone to whom I am explaining how an why. Thirty years later I can look at any of my code and quickly understand it. In sharp contrast to this I find most open source code to be difficult and laborious to understand due to the almost total lack of useful comments.

JustSomeNobody 7y ago

> Learned as junior: New tech solves old problems. > Understood as senior: New tech creates new problems. This is one all the people who push "new and shiny" need to learn.

giancarlostoro 7y ago
I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. Or would you rather everyone stick to coding in VB6? I rather we all use C# instead of VB6 ;) I'm not implying we only ever use C#, I know there's other languages, just illustrating a shift in the MS windows development ecosystem that was for the better.
- JustSomeNobody 7y ago
  > I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. I don't believe this is the spirit in which this was meant. If the old system is out of date and there are buggy libraries that aren't being maintained, that is a WHOLE different issue.
- kerng 7y ago
  VB 6 is probably not a good example. Even nowadays many languages don't have features that VB6 offered incl. WYSIWYG. Debugging capabilities of modern languages/environments are still often not even close to what VB6 offered 20+ years ago. C# certainly is outstanding but I think Microsoft made a gigantic mistake by killing VB6 the way they did. Microsoft's prevented a large amount of people to write applications, since a new ecosystem like C# or VB.net was significantly more difficult to learn and understand. In retrospect Python or Node probably took VB6's place, so Microsoft just lost out on a huge market there. Bad management decision.

kps 7y ago

Lemma: > Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read. Lemma: > Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most. Theorem: Communication needs to target the people of the future.

beat 7y ago
Outstanding observation, thank you!

LordHumungous 7y ago

> If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Similarly, one thing I learned is that if I find a bug with an OS or platform, 9 times out of 10 it's actually due to some problem in my code or my own lack of understanding :)

loco5niner 7y ago
Can suggest it's more like 999 times out of 1000?

enobrev 7y ago

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git reset --hard HEAD` or end up with a similar solution, but with better comments Once in a while, I end up with a [simpler | faster | clearer | otherwise better] version, which makes this process worth while - even with the false positives.

sbmthakur 7y ago
> Re-realize the edge-cases and difficulties I think comments can help avoid such scenarios.
snicky 7y ago
Semi-related story of mine: 1. Stumble upon some specific problem with a web framework we use. 2. Jump straight to stackoverflow. 3. Sbd had a similar issue, nice. 4. Sbd wrote a very concise answer, nice too. 5. There's my nickname under the answer. Oh, wait...
- grogenaut 7y ago
  I'm getting the statement about once a quarter at work of: Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.
  - eitland 7y ago
    Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.
    - gambiting 7y ago
      I'm sad that I cannot share my experiences the same way :-( 99% of my "interesting" bugs are almost all Xbox One/PS4 related, so I can't write a blog post about "how I found out that Sony's implementation of file read is not compatible with regular stdio" - it's hugely interesting but this stuff is NDA'd to such an extent that I wouldn't risk writing openly about it - but I'd love to.

taneq 7y ago

> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.

yakshaving_jgt 7y ago
I wish my mother knew what a compiler was.
- taneq 7y ago
  Heh, at 19 she was the PL/1 expert for the Asia/Pacific region. Mum's a badass.
beat 7y ago
One of the first rules from the book The Pragmatic Programmer is "SELECT isn't broken". (It might even be the first rule.)

kbenson 7y ago

> Understood as senior: Legacy code that I wrote myself is hard to read. As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then.

toxik 7y ago
I disagree with this perspective. You of yesteryear is in many ways just another programmer you have to work with; if that makes you cringe, you may be taking a bit too much pride in your work.
- kbenson 7y ago
  > You of yesteryear is in many ways just another programmer you have to work with Taking that idea to the extreme of not having any feeling of ownership or pride (or lack thereof) in your past work seems rather silly to me. It wasn't just some other programmer, it was you. I'm not saying you should cringe because the code is bad, but because you should have a sense of "well, I could have saved myself some trouble or made this cleaner/more obvious if I only knew then what I know now."
  - Retra 7y ago
    Or maybe you cringe at your old 'good' code because you spent too much time on things that ultimately didn't matter.
fendy3002 7y ago
It isn't as simple as better skilled or not. Many times having more understanding about the problem may open your eyes to better / simpler design, or you now don't have any rushing matter that fuel bad design in the past.
Scarblac 7y ago
There are absolutely things I was better at back then, mostly because then I spent all my time doing nothing but programming and now a lot of time goes to other activities (meetings, planning, writing, etc).

alkonaut 7y ago

New tech solves your existing problems and creates new ones. I have a big pile of problems I have had for many years that I’d love to trade for some new ones. I’m happy to fix one problem and get 5 new ones. I’m happy to get rid of an easy problem and get a new much harder problem. The important thing is that I get some new problems, and nothing will do that like new tech.

Gibbon1 7y ago

> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. Me: 'Even a blind squirrel finds a nut once in a while'

cja23 7y ago
Horses, not zebras. But yes, there are a few zebras in the world also.
- Gibbon1 7y ago
  Depends on what they are doing. Oh you found a 'bug' in Mac OS, Windows, or Linux? Probably not. Oh you found a 'bug' some open source library? Maybe. Or in our in house developed framework? Probably. In house framework I wrote? Certain of that.

bpyne 7y ago

"Understood as senior: Legacy code that I wrote myself is hard to read." Your comment came at the perfect time. I just finished debugging a "high urgency" problem with a program I developed and maintained for the past 10 years. The program started simple with a small list of rules to apply against data sets. Over time the list became a tree of rules that expanded in both breadth and depth. It was refactored once to get the design in line with the rules of the time. The "high urgency" issue turned out to be the program working correctly. But, the functional user wasn't able to keep in mind some of the rules he set. It took me a half hour, with lots of "why did I do that", to explain it again to the user.

jshowa3 7y ago

Things I've learned: I'll never be a senior programmer.

justbaker 7y ago

>Understood as senior: Communication skills matter most. I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.

kenhwang 7y ago
There's also a strong correlation between strong communication skills and strong technical skills in our industry that demands frequent learning of new skills. So not only does strong communication augment technical skills, it also signals its strength which is also valuable to software developers.

chadash 7y ago

> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell him that the data isn't ready because there's a bug in Excel. I was laughed at by the entire team. They agreed to give me $1000 right then and there if it was really a bug, but if not, I had to admit the shame. Well... of course it wasn't a bug in Excel, I just made a careless, albeit hard-to-find, mistake. Lesson learned. If millions of people use something, that doesn't mean it doesn't have bugs. But it does mean that you probably aren't going to find those bugs unless you are doing something strange. oddly, I did once find an actual bug with indexes in Postgres. Because of my earlier experience, I spent a lot of time assuming it was me before I finally isolated it as being a bug with postgres itself. I submitted a bug report and it was patched within a day. But still, 99% of the time, it's me.

xmprt 7y ago
You can't tease us like that without explaining what the "bug" in Excel was.
- chadash 7y ago
  As I said, it wasn't a bug in the end :) The issue was with my formulas, but I don't recall exactly what I did wrong. It was a tiny typo I made a sheet with thousands of formulas if I remember correctly.
beat 7y ago
I actually found an OS bug in AIX on my first real I-designed-this code project. Worse, the bug was discovered only when the code went into production - it behaved differently on the test servers than on the production servers! The bug caused mmap() system calls to randomly overwrite certain pages in memory with NULLs. Yeah, that was fun. And it was caused by the order in which patches had been applied, which was why it behaved differently in production than in dev/test. If some second year programmer told me that nonsense, I'd make them go back and either find their bug, or write a test program that exercised the bug in isolation (which was what I did).

bunderbunder 7y ago

> Understood as senior: New tech creates new problems. Related: There are no new problems.

SkyMarshal 7y ago

>Learned as junior: Technical skills matter most. >Understood as senior: Communication skills matter most. I see this often, but it needs to be said with a caveat - the second line presupposes the first. Without the first, the second doesn't really matter (or it does but you're in the wrong career).

retiredcoder 7y ago
Actually it is very disfuncional for me to be in a company that communication skills are ahead of technical.

TheAceOfHearts 7y ago

Sometimes you encounter some questionable code and you wonder: "What idiot wrote this?" So you `git blame` and you find out "Oh, I'm that idiot."

retiredcoder 7y ago
I have been in this situation and tried to remember what was going on while I wrote the questionable code. It frequently came down to a day full of interruptions and context switching. Also motivation plays a tremendous role, I know that whenever I have to work on a code base I don’t understand and don’t want to have anything to do with it long term, it ruins my ability to focus.

whatever_dude 7y ago

> Understood as senior: Communication skills matter most. I've been of a similar opinion at some point, but now that I see people _optimizing for communication_ as juniors in lieu of actual technical skills, I say: both matter a ton. I hate dealing with a junior that is an extremely good people person but a terrible developer: they tend to think they got everything covered just because people like them so much, even when their actual solutions are terrible.

philwelch 7y ago

> Learned as junior: New tech solves old problems. > Understood as senior: New tech creates new problems. Yep! When you use "new tech", you're making a bet, and not all bets pay off. If you're cautious, you'll hold off until new tech is proven (or pilot it cautiously before migrating). If you're possessed with good judgment, you'll be discriminating in which new techs you adopt. If you have both virtues, you may even gain a competitive advantage.

bsder 7y ago

> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. And, yet, it does happen. The important part as the senior guy is to make the junior guy create a test case and then cut it to the bone until it is obvious where the bug is. Story time: It's mid ninteen-ninety-mumble and your intrepid hero is a junior programmer handling multi-site integration and testing tool infrastructure. This being the time when the Swiss Army Chainsaw(tm) (aka Perl 4) is well and truly entrenched in the sysadmin and toolsmith programmers, my technical superiors throw me a couple of Perl books, set my deliverable date impossibly soon, and tell me to get going post haste. So, I code. It's not a lot of code, but it is parsing and matching files in 3 different formats from 3 different sites. Of course, I hear what you are saying: "Perl and parsing is like mixing ammonia and chlorine--and probably more painful." Yes, I concur. But, it is the tool at hand in the long forgotten mists of time when RAM was expensive and spinning rust still resembled an iron brick. So, off I go with regexes for parsing (Yes, I know, now I have 3 problems). And everything worked quite swimmingly. Except for a bit of idiocy that nobody could track down that occasionally flagged a couple of records as mismatched when manual inspection showed they really were not. Nobody minded that much as the scripts got 99.99% of the job done and didn't give a false negative, so: "Ship it, junior." And so we did. However, the bug annoyed me because I had to got clean up the false positives when they fired. And, if I am anything, I am a VERY lazy programmer--and this was preventing me from being lazy. So, I eventually am waiting for one of the other groups to deliver, and I go spelunking for a testcase. Spelunking? HAH! Cave diving is a better analogy. The program took the most inclusive of the syntaxes, used each record from that to build a regex to look for the corresponding record in the other syntaxes, matched what it could and flagged what remained. So, the program was building a dynamic regex on-the-fly and then using it. Not a huge deal, but the regexes were larger than most people were probably comfortable with. No problem, I validated this on much smaller records out to REALLY big records, and they work well. Except for those weird cases ... So, I'm looking through a case that works and trying to compare it to a case that doesn't. And I accidentally fat-finger some character set match and delete a character that shouldn't matter. And the regex fails ... provoking the Asimovean "That's funny ..." So I delete another character ... and it works again. What?!?!?! So, I add a character. And it fails. And I add another. And it works again. I stared at that regex for what felt like EONS until the light bulb went on. The one that worked? 511 characters or 513 characters. The one that failed? 512 characters. So, yes, I, a total Perl n00b managed to find a bug in Perl 4 in my first ever Perl program. Sometimes the junior dude gets really unlucky and finds an actual system-level bug.

jv22222 7y ago

> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you Same thing happens in reverse! ;) A few years back I told 3 devs who reported to me that there was a bug in Laravel database sub system. The bug was: If you use the word "returning" in any Laravel insert query the system would crash (Laravel 3 & 4). None of my guys would believe me! I finally tracked the bug down to > laravel/database/connection.php > public function query($sql, $bindings = array()) > { > ... etc ... > elseif (stripos($sql, 'insert') === 0 and stripos($sql, 'returning') !== false) I sent an email to the Laravel team and never got a response... but the bug stopped happening some time after that ;) I think it was relate to mySQL version as well.

deleted 7y ago

[deleted]