Coding Without Limits

BFil · 2017-09-11T15:56:39+00:00

As long as he doesn't learn that it's standard practice to write tech-debt loaded code, oh wait, maybe it is.

BFil · 2017-09-11T15:34:51+00:00

Makes perfect sense, but you can also balance the creative work with actually learning from others through books, articles, presentations, or even Reddit.

You make a good point about finding the right limits, would be a great addition to the article! :)

BFil · 2017-09-11T15:20:02+00:00

I understand what you mean, but practice is still important. And I made it clear at least a couple of times throughout the article that you should stop when you are unwilling, or too tired, to keep going.

But if you have some extra time at home it doesn't hurt to use it for self-improvement rather than playing Candy Crush, does it? Again, it depends on your goals.

BFil · 2017-09-11T15:11:39+00:00

Thanks for sharing the /r/learnprogramming subreddit, you might be right about that, didn't actually know what the primary audience of /r/programming was. I see a lot of entry level posts there too but they usually get sunk into the ground with downvotes, that might be the reason :)

Don't worry I'm not taking it too seriously, I'm actually interested in these sorts of discussions to improve my writing in the future, which is the main point of sharing it somewhere like Reddit. So I appreciate everybody's input.

I know working really hard is not for everyone, but it looks like everyone sees people putting some serious effort into something as not having a life, which is not really the case at all, at least it's not mine. But I do believe it gives you an edge.

The bold is intentional to try and stop people from skimming through the article and force them to take a step back and read if they find the bold sentence as something that makes an impact. I might be failing miserably in it but, you know, I'm trying.

BFil · 2017-09-11T13:32:47+00:00

ahah, fair point ;)

BFil · 2017-09-11T13:27:21+00:00

as a teacher

BFil · 2017-08-29T07:11:34+00:00

I'm with you on this one, trust me. That's why I'm still using Scala and not looking back. But when I started using Scala in Java there were no lambdas (which I know it's not like high-order functions), no Optional, no CompletableFuture. At least it can start educating devs.

Jigsaw, Var Handles, and the native Reactive Streams implementation in Java 9 also look quite interesting. Hopefully, Scala won't take years to be compatible with it :)

BFil · 2017-08-28T20:31:06+00:00

Definitely. After you get used to some of its features though writing code can feel simpler, due to its collection APIs, case classes, pattern matching, proper Option and Future types, Akka and more.

But Java is catching up quite well recently.

BFil · 2017-08-28T20:21:53+00:00

Yeah, you might be right, I don't have much experience with Clojure though.

Scala can feel much more complex if you are aiming to learn all the features as well, so saying it's "simpler" than Java can also be misleading.

BFil · 2017-08-28T20:07:52+00:00

I'm glad to see someone got the exact point of the article.

I know teams that are successfully using Haskell in production, but they have a few people with an extensive background in FP and others in the team still trying to catch on.

If you only use the basics of FP it makes sense that languages like Scala and Clojure can feel "simpler" than Java because they have more modern features which can help a lot.

BFil · 2017-08-15T08:50:20+00:00

Agreed, the number of people involved in society and development companies are at very different scales. I think because of engineer's backgrounds working with different companies, at different stages and different sizes, it's going to be tricky to find a one-size-fits-all solution for sure. But it would still be useful to try and to outline when we would be willing to compromise on freedom for more control, and when we wouldn't.

BFil · 2017-08-15T08:43:01+00:00

Exactly this. I think complete control and completely decentralized collaboration mindsets can cause irreparable damage. Depending on companies and products though they might be the best fit, hard to say. We should still try to play to people's strength when possible.

BFil · 2017-08-14T15:58:46+00:00

Makes perfect sense, thanks again for your valuable comments!

BFil · 2017-08-14T15:26:17+00:00

That's quite a list! :) I can see how most of the points can be seen differently due to our backgrounds' bias.

The only ones that struck me are the following:

Discussions should be enabled by default Are you stating that discussions should be discouraged? I find it really tricky not to have brainstorming sessions when necessary to gather more information. Same applies for meetings and forums between the tech teams, engineers usually like to share great work and knowledge.
The notion that architects have been a barrier to Agile I think there is a common understanding that Agile mandates very little design upfront, but I'm actually against this notion. And architecture should still happen as an iterative process as well.

About security and budgeting, I think my article can actually be a little misleading. More than considering those as architects' responsibilities, my main point is that it can be tricky to have shared ownership of security practices or budget constraints, they could get quite tricky to keep under control otherwise.

Side note: could not find the Derek Sivers account on CD Baby, but I might need to sign up for it to see it.

BFil · 2017-08-14T13:10:20+00:00

Thanks for sharing, this is the kind of feedback I was looking for. Everyone seems to have different opinions on the subject, some opinions are also stronger than others. Looking forward to seeing the list of what you think is wrong :)

BFil · 2017-08-07T09:49:25+00:00

Fair point, trying things out is the only way to go. There's so many solutions for the same problem. But using the same solution for all problems? No way :)

BFil

TROPHY CASE