conrs

Great idea, I went ahead and implemented it on my own site: https://con.rs

Howdy, I took a stab at adding some of these features to my own implementation, the tab completion is pretty rudimentary though. Clickable things was a great idea, I have ls's output as a link that auto runs the corresponding command to view the content.

https://con.rs if you're curious!

I took a stab at adding some mobile friendliness to my own implementation, if you wanted to take a look: https://con.rs

Howdy - I know I'm digging this up from the past, but your comment prompted me to add some mobile friendliness to my own take at this: https://con.rs

Of note - autosuggest options, clickable links for ls output.

I forgot to follow up here, so apologies for the delay. Honestly, concise is a challenge here. Here is a lot of words, and they barely scratch the surface, but just in case they might be helpful:

- Embracing the idea of a manual valuable process is a great one - as engineers we often want to start by automating and/or building, and dive right in - only to realize later we either didn't understand the product, or our stakeholder didn't and now wants changes once they've seen what it does. (Deeper dives here: "Escaping the Build Trap"[1], "The Minimalist Entrepreneur"[2]

- Understanding negotiation is extremely helpful as you are often operating under constraints, and need to get those across to your stakeholders such that you can both move forward together. Negotiation is basically about aligning two stakeholders with different goals and arriving at an arrangement they can both live with. (Highly recommend "Negotiate without Fear"[3])

- Another excellent concept surrounds the theory of constraints and getting good at recognizing bottlenecks, and subordinating all other processes to them. Essentially, if work is piling up somewhere, look at where it is coming from, and attempt to re-route those efforts to something productive (the bottleneck moves the same speed regardless of how much work is piled up in front of it). The classic book on this matter is "The Goal"[4] but a fun retelling more oriented around an IT department is "The Phoenix Project"[5].

[1] https://www.amazon.com/Escaping-Build-Trap-Effective-Managem... [2] https://www.amazon.com/Minimalist-Entrepreneur-Great-Founder... [3] https://www.amazon.com/Negotiate-without-Fear-Strategies-Max... [4] https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0... [5] https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

I've had a very hard time with the Product Manager discipline. From the books and podcasts like Lenny's, it all makes perfect sense, but it seems like in practice it is as you described - they've inserted themselves in between and often don't represent either side well. It's lead me to develop product management skills myself, which are honestly incredibly useful in avoiding wasted effort. But it does make me wonder whether the dichotomy is worth it or if product management should be part of a senior engineer's skillset.

Link NSFW - props on style though.

Awesome! We should talk, very curious about your implementation.

https://con.rs (a refactor, limited functionality) https://blog.con.rs/series/#mash (posts related to the saga of development, recently revived!)

Also stealing all these ideas from the comment thread on how to improve it :)

Having a downstream engineer to hate your guts is a good problem to have! It means your product succeeded for that long, and that it is still relatively well funded.

Most products don't get this far.

Highly recommend reading or listening to The Goal. The audiobook feels like a cheesy training video, but sort of in a good way, and the concepts are extremely useful. Plus, you learn the language it is more likely your business counterparts know, as opposed to talking about backpressure or queuing theory, which they may not connect with.

I use the concepts from this book all the time at work to justify a prioritized backlog and defend against a lot of work in process.

Work on solving problems using declarative languages and functional languages.

So, either Prolog, or Lisp.

Structure and Interpretation of Computer Programs is a good jumping off point for Lisp while also providing fundamental insights.

Prolog.. honestly, just google "basic" array problems and try and do them in prolog. It takes a mental shift, which is hard at first, and you feel silly not being able to count to 10. But learning how to think in this paradigm is useful - e.g. SQL is declarative.

Here's the thing. They are telling you they value these things as a signal. You as a candidate can be as frustrated as you want, but throwing a tantrum doesn't actually do anything.

I agree with you that writing in a non IDE and with no REPL is ridiculous. But... That's what they want. Clearly you aren't a fit for each other, why not leave it at that?

I think we've all wondered this at some point in our careers.

It's something you should never do. Off the top of my head:

1) Security (as has been beaten to death here)

2) Interface versioning. If you expose a generalized SQL interface to your consumers directly, good luck ever making a change to your database schema. You'll have no idea whose workflows you break. This high coupling becomes very painful very fast.

3) Abstraction. The way data is stored is often not the way data should be surfaced. What about application layer data integrity, things like that? This would require the frontend client to have far too specialized of knowledge as to how the backend works.

4) Optimization. How do you optimize for queries you don't control? Someone will craft something that can bring your database to its knees under load without even trying to.

I too find ADHD to be a super power. We've been forced to adapt to our inability to pay attention to uninteresting things. But a lot of the day-to-day life doesn't really help you in the long run.

Props on vo.codes; I'm [refactoring my website](http://blog.con.rs/2020/09/11/mash-rehash.html), one piece of which is a "say" command currently powered by online dictionary. Seems a super simple fit to power it using your tool instead :)

[]