6 ms·

Some things I've learned after 35 years; 1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I w

• metters 7y ago
  Could you please elaborate the "coding is not a social activity" or offer a reference. Thank you very much in advance! reply
  • carl_sandland 7y ago
    np. The "Stuff" that surrounds coding is very social (point 1), but the actual activity of writing code is very inward focused and ideally uninterrupted. The idea of FLOW is a very real thing, its very zen: hours just fade away until you look up and everyone has gone to lunch. I'm tilting at the open office windmill and idea that whilst I'm actually coding, I need to interact with others. Being a "Developer" (planning, designing) is very social, however writing the actual code, for me at least, is a very inward activity and suits my quiet personality. The problem here is that non-coders don't understand this and it can cause a lot of friction when working in the usual group office environment. It's a catch 22, people want me to code for them, but then they have a problem with me socially when I'm trying to code ;)
    • metters 7y ago
      I agree with that and can also relate to this point (as I experience exactly this in my current project) my colleague already complained about being interrupted many times already. The problem is that the non coding colleagues want to ask just a 'quick question'. Thanks for the quick reply.
    • iamsb 7y ago
      What do you think of pair programming and the more extreme nature of it called mob programming. Have you seen either of those two things work well in any context?
      • randomidiot666 7y ago
        Pair programming was never intended to be a full time mode of development. Half an hour once a week (or whenever) is good enough, and can help with mentoring junior developers. But it is really moronic to do that full time.
        • dorfsmay 7y ago
          "intended"? By who? Based on what? I worked at companies that had full time pairing and it worked well. When you tried full time pairing, what were the issues you observed that made you conclude it was "moronic"
          • randomidiot666 7y ago
            .. by the people who started it and popularized it. I have never tried it full time because it's obviously patently moronic to do it that way, and would destroy all enjoyment of the job. I have worked with highly talented developers and can not recall any one of them wanting to pair full time. I have received huge benefits from occasional pair programming with senior developers in my less senior days. However, I need to try full time pair programming as much as I need to try jumping into a fire to verify that it's not a smart idea. If my employer forced me to do that I would quit on the spot.
          • deleted 7y ago
            [deleted]
      • dmarinoc 7y ago
        I’ve only seen mob-programming to be adopted by teams of junior-slackers, but YMMV
      • carl_sandland 7y ago
    • jbverschoor 7y ago
      Pair programming works if used as a mentorship. You’ll need to have a senior dev and a less experienced one. But I guess this is but the original intent of pair programming
    • peruvian 7y ago
      This is off-topic, but I have never experienced the "flow" you mention but I've had a decent career so far. I'm not the best or anything but I've done well in terms of promotions or projects shipped. I've never lost track of time coding like you say - I stop at 12:30pm for lunch and then at 5:00pm to go home. I've always wondered if I am doing something wrong or maybe I just like programming enough as a job.
      • chownie 7y ago
        Being able to enter that state isn't reliable even for people who do it often. I've never been able to do it at work, it happens somewhat often when I'm doing home projects if my environment is suitably quiet. I've found that I experience a kind of embarrassed reluctance to fully commit all my attention to something while I'm at work surrounded by people, that prevents it for me.
        • StavrosK 7y ago
          I get it reasonably often when I'm coding my projects late at night, when there's nobody there to bother me. The downside is that it messes with my sleep, since I'll start at midnight, write some code, think "okay I need to go to bed by 1 because I haven't been sleeping well" and I look and it's 5 am.
      • tempguy9999 7y ago
        I agree, I've heard of 'the flow' but it's never happened to me. Perhaps related, perhaps not, I never 'sink in' to films I'm watching. My old GF seemed to be able to, but I'm always on the outside looking in, never immersed. I wonder if that's linked.
        • peruvian 7y ago
          I’m the person you replied to - I’m a big film fan but I have the same “issue”. The only time I can get immersed is at a movie theater and even then it’s rare (last time I was immersed it was with Parasite). But again, I enjoy the film and am able to remember all of it so not sure if it’s a problem.
• amake 7y ago
  This is unreadable on mobile.
  • thdrdt 7y ago
    I'm also having a hard time swiping the text. So ahead of the poster: 1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice. 2. question all assumptions. 3. there is no silver bullet (read mythical man month). 4. fight complexity and over-engineering : get to your next MVP release. 5. always have a releasable build (stop talking and start coding). 6. code has little value in of itself; only rarely is a block of code reusable in other contexts. 7. requirements are a type of code, they should be written very precicely. 8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function. 9. release as frequently as possible, to actual users, so you can discover the actual requirements. 10. coding is not a social activity.
  • deleted 7y ago
    [deleted]
  • GordonS 7y ago
    A bit OT, but I really wish HN supported markdown in comments - with the current system, I often find it difficult to format as I intend, especially while on mobile.
• modernerd 7y ago
  What formal training do you recommend for cultivating social and communication skills?
  • carl_sandland 7y ago
    That's a really good question; I'd pay good money for developer focused communications training. Some practical ideas; 1. try to engage at work with more activities, you'd be surprised what activities you can help out with, or maybe arrange. 2. never pass up a customer focused activity, volunteer and push to be involved. 3. ask a sales or business guy at your company to be a mentor. 4. talk to random people beyond small talk (parties?). 5. read books (mileage varies). Something like "toastmasters" for coders would be so cool.
• samvher 7y ago
  Not sure I agree with 6. I find that if you develop for reusability and you're a bit creative you can actually reuse a lot (though it might depend on how tightly you define "other contexts"). I have to say that functional programming plays a very important role in this though.
  • mihaaly 7y ago
    all reusability have limits! usually work is carried out to satisfy a set of requirements. as long as requirements are matching old ones in a different task then the product can be reused but in case there is deviation then alterations will be required to address the differing bits. we may predict future requirements and address those too through generalization but that must have limits as addressing predictions is by definition not certain, may need refactoring still in the future while using actual resources. even the stl of c++ needs rework as it does not address certain requirements or address outdated ones. no code will be reusable completely all the time, in fact only reusable if specific circumstances match. generally speaking generalization is impossible.
• gilbetron 7y ago
  Spot on - 40 years of coding, 33 professionally, and your list resonates with me. I'd also add: write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works. Mostly, though, I can tell a grizzled veteran (and I've known some that hardly had any years under their belt, it's all in the soul!) because they rarely claim to know The Answer, and have a weary self-confidence that, even though they don't know how, they will get the job done. Last year, after experiencing several individuals that fit the term, I came to calling some people "Medium Developers" - generally falling in the 4-8 years of experience, that get much of their knowledge from Medium articles, and believe the dogma wholeheartedly. Complete lack of nuance in all things, and are very evangelical about their dogma. Shitty managers are enthralled with them, and the code written (slowly) in such situations is horrific. "Throw it out and do it the Right Way (tm)" is the mantra. Honestly, the blog post in the OP sounds like a Medium Programmer. They're worship of TDD is one symptom! "I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!"
  • jmilloy 7y ago
    > write code in tiny pieces where you don't do the next piece until you're confident the current piece works. I get fidgety when I have a bunch of code I don't know works. I think getting to this point really helps with the "flow" issue ("coding is not a social activity"). The more you can isolate small steps, you can more easily weather interruptions. > They're worship of TDD is one symptom! My suspicion is that this person is very good at writing the tests, at the right level of isolation and detail, and that watching them work would feel less dogmatic that the text of the blog post suggests.
  • JimboOmega 7y ago
    > "I don't know, but we'll figure it out" is what I like to hear, versus, "This is how it Must Be Done!" I've had this argument multiple times recently. Usually when I say the former the response is something like "But how can we really estimate it or plan it before we know exactly what we're doing" Writing overly detailed requirements without coding gives me the same feeling of fidgetiness you mention. My attitude is "Plans are worthless, but planning is essential" , and you have to cut off design at some point because the risk (that you discover something in coding that invalidates the plan) outpaces the value (of knowing what you're doing). Reminds me of another problem I've seen recently - an obsession with writing code that is "overly correct". There are times where a small change of a few lines accomplishes a thing but produces some undesirable side effect - it breaks an expectation somewhere, for instance. But the alternative is rewriting a huge portion and adding a ton of code and adding complexity as a result, even if the methods and their responsibilities are more clear. "Throw it out and do it the Right Way", in other words. We've become very conditioned (especially mid-career) with focusing on never allowing tech debt and doing it the right way. But sometimes you actually add complexity in trying to achieve perfect cleanliness. And in fact, even if the resulting code is slightly less complex, there is a lot of risk in the rewrite. At my stage of my career - 15 years - the biggest conflict I see is between business that wants estimates and the inherent unpredictability of writing software. Business wants the list of things I'm going to get done, meanwhile I want priorities. Are you able to say "Hey, this thing I thought might take a week is actually a quarter long project, should we set it aside knowing that?" Often the org is simply not flexible enough to handle that (or handle scoping it down so it can get done in a reasonable amount of time). I'd almost say what you describe is the sign of a mid-experienced manager, too. They've realized it's important to shield their team from some organization problems so they can write quality code (moving past the "yell at them until it gets done" phase). But they haven't really learned how to get past the mid-level engineer obsession with beautiful code, or to handle the general complexity of the inherent clash between business goals and engineering goals - they've gone full towards the engineer side of that spectrum.
• odiroot 7y ago
  > 10. coding is not a social activity. I wish multiple tech leads I've interviewed with, here in Berlin, realised that. There's just so much cargo-culting around XP.
• the_other 7y ago
  Nice list. Thanks. I’m gonna clip that an ruminate on it a bit. I dispute 10 strongly, tho’. Our projects are largely built collectively, for collections of people and machines; use community derived patterns and practices; are typically too large to keep the whole thing in (human) working memory; are better with code-review.
• jmilloy 7y ago
  Great list. (1) and (10) seem at odds, or alternatively are tautological; I think the important thing is to acknowledge that social and isolated modes are both required to develop software, and that getting the balance right is hard, and isn't the same for everyone. Seems to take people a long time to figure out (4) and (6). (2) and (3) and (7) really apply to most things.
• rsmckinney 7y ago
  Sage advice from an obvious veteran in the field.