1. 2

    I love On the Metal Podcast! all the episodes have been amazing :D

    1. 2

      This one was the best to me.

      1. 4
        1. 1

          thanks!

      1. 2

        I’ve been at both ends of the spectrum. In the end, what I’ve realized is that I like to solve problems and help other people. Be it code or just talking with people in meetings.

        I think it has to do with the myth of the ‘10,000’ hours to be “good” at something, so folks code after work to reach it ‘faster,’ but if you’re doing the wrong type of exercise, then the 10,000 hours don’t mean anything.

        I think in the end, is just accepting that everyone is different if someone wants to code after work doesn’t mean he’s better or worse than you, or that you’re better or worse than him. Stop comparing :)

        1. 3

          I always leave at 5; I try to avoid ‘being in the middle of solving something’ and working with such small increments that I can stop and continue at any time. Because during the day, there will always be people, meetings, even walking to get water. In my opinion is better to avoid being in ‘the zone’ so I don’t feel any type of pain being interrupted.

          1. 3

            This is interesting to me. I hear a lot about “flow” and “zone” lately and I find that I would rather have many small periods of decent productivity (interspersed by unavoidable context switching) than get upset at inevitably having my flow broken.

            1. 1

              I suggest finding a way to get back in the zone. It’s productivity benefits are incredible. It feels great, too, with who knows what positive benefits in your mind. Maybe find a way in your practices or talking to management to reduce interruptions or make them happen outside of zone time.

              Alternatively, consider finding a better job where you can be in zone. This could be worth talking to their employees about, too, when checking on the company before applying.

            1. 1

              I’m thinking of attending Velocity, and some JS conference which I haven’t decided.

              1. 3

                Searls is an outstanding presenter, I enjoyed this talk very much!

                1. 1

                  Technical debt is something that always creates an internal debate for me. In some cases, I believe that it is our responsibility as engineers to “fight” against it, through the use of well-known refactoring techniques and being efficient on time management to improve code even when adding new features. But sometimes (or most of the time) you always have the pressure to add new features to the system, and how you sell that the feature is going slow due to not being able to “just add the feature” but instead you have to move things around to accommodate the new feature?

                    1. 6

                      I have learnt never to say “Technical debt”.

                      If you say “Technical debt” to the business end, you’ve lost already.

                      Because then you have to explain what the problem is exactly. And you run in to the Manager’s Syllogism.

                      You know the one, “Manager’s are Important People. They know and Understand Important Things, if XXX was Important, They would Know All About it.”

                      Ok, I’m exaggerating for humorous effect, but the point is compared to everything else on the list of things they want done, Technical Debt is really low on the list…. and most times falls of the list of things To Do This Cadence. Again.

                      Or worse, “So you’re saying this mess exists because your Managers are Bad and your colleagues are Worse? And now you expect me to trust you to go off on a long rewrite?”

                      I distrust rewrites.

                      They are never as Good as Hoped and always take way way longer than expected to get up to full functional equivalency. In fact, usually never do. In fact, I’d argue most of the benefits of a rewrite is in deleting cruft nobody really needs.

                      So start there.

                      Delete cruft as you go along every time you see it.

                      If someone yells and really wants it back… hey that’s what version control is for.

                      So merely say, “It will take X amount of time.” Why so Long? “Because that is the way the existing code is. (You can start explaining it to them until their eyes glaze over..)”

                      And then fix the existing code.

                      When you need to fix a bug, write a unit test that stimulates it. Then tidy up the code until it is so simple the bug is obvious. Fix the bug.

                      When you need to add a feature, brace exiting required functionality in unit tests, write a unit test to add the new feature, watch it fail, clean up the code until it’s trivial to add the new feature, add the new feature, watch it pass.

                      Technical Debt? What’s that? Heard of it once, not a useful concept in practice.

                      1. 2

                        Thank you so much for this. Really really useful!

                        1. 1

                          Thank you! Will read it :)

                      1. 10

                        Huh. I didn’t realize Java is going the Firefox/Chrome model of releases.

                        Overall if you have good unit tests in your software, this shouldn’t be a big deal. Update to Java x, run sbt test or gradel test or whatever, update your test-running CI container to java x, let it run there, update your production Dockerfiles to java x, deploy and check your integration tests.

                        Oh you don’t have a lot of unit tests? .. wait, you don’t have any unit tests?! … Well it will probably just work .. have fun!

                        1. 6

                          I don’t think it’s that straightforward for everyone. It’s hard to measure the performance impact of changes to the JVM, as well as potential obscure bugs, from just unit testing. I think most big deployments and libraries will stick to LTS releases as a result, which isn’t that bad given it’s about the old pace of updates anyway.

                          1. 6

                            To support this point, for a specific example of a more obscure change in a JDK that caused programs to fail, see http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html - it’s a long list but note this

                            Collection.sort defers now defers to List.sort

                            Previously Collection.sort copied the elements of the list to sort into an array, sorted that array, then updated list, in place, with those elements in the array, and the default method List.sort deferred to Collection.sort. This was a non-optimal arrangement.

                            The consequence of changing to sorting in place (the optimal arrangement), is that programs which sorted in one thread and concurrently iterated in another are more likely to crash with this JVM than previously. Might be hard to test for that even in an integration test!

                            Unit testing is dangerous because it gives inexperienced coders false confidence that changes are good.

                          2. 2

                            Huh. I didn’t realize Java is going the Firefox/Chrome model of releases.

                            Well, at least Firefox has train releases + a long term release. Java doesn’t seem to have that.

                            1. 11

                              Didn’t the article mention Java 8 being a long term release?

                              1. 13

                                Yes, Java has LTS releases, currently 8 and then 11. http://www.oracle.com/technetwork/java/eol-135779.html

                                1. 4

                                  Ah, sorry, I had missed the precise scheme. I thought 8 was LTS, as it was the last “old-fashioned” release.

                                  1. 1

                                    Note that Red Hat will support OpenJDK 8 after Oracle discontinues their support as they have with previous releases in the past; they commit to it up to October 2020: https://access.redhat.com/articles/1299013

                            1. 3

                              Curiously, the same is on Wikipedia.

                              1. 1

                                Thanks for taking the time of putting this list together!

                                1. 5

                                  I’ve felt some of the toxic behaviors written here, some teams I’ve left and others I’ve tried to change the behaviors. Especially because we’re a mixture of native and non-native English speakers (writers?), so sometimes even though it sounds cordial in Spanish it may not in English.

                                  I think in the end, you just have to talk things, if you don’t like the tone of a comment then say it for improvement.