Does anyone have any advice on how to become an auteur software engineer? I've tried visual programming, functional programming, and several others, and they are just so much more enjoyable and powerful (in a specific sense akin to productive) than mainstream languages like Python, C++, etc. But I'm relatively exhausted by having platforms dictated to me by the middle of the bell curve and, frankly, people not experienced. Even as something as simple.and pragmatic as F# or Elixir seems to make people step back from you, as if you're cursed, much less something like Smalltalk. At this point in my career, I have given up and am just going to use Python and C++ like everyone wants you to. It's been a big enough hurdle yo probe that Incan write in Python and C++ despite having used a plethora of languages.
So, how do you use these powerful platforms banished to personal projects? How does one get into a position such that you can dictate the platforms used? Is there anyone who has done this?
It's an unfortunate case of people having the interesting applications having a very tunnel visioned view of what could be with software.
Real programmers can write Fortran in any language.
I don't write Fortran, but I can make my C++ look a lot like a different language. Knowing how those other languages work makes my code better. Sure the C++ syntax is ugly, but the design is what matters and that take inspiration from languages other than C++.
Real programmers can write Fortran in any language.
I don't write Fortran, but I can make my C++ look a lot like a different language.
That sounds like the wrong thing to do and a nightmare to encounter. I guess I'm not a "real programmer", which bolsters my original point.
Knowing how those other languages work makes my code better.
Knowing is good. But it goes both ways as well. But C++ devs are fairly notorious for not liking different things. See Rust's history.
Sure the C++ syntax is ugly, but the design is what matters and that take inspiration from languages other than C++.
The syntax isn't the point, or is at least a minor one. The main point is that languages like C++ make designing harder than it needs to be. Also, in a language like C++, nearly anything can happen at any moment. It's like rolling dice for every function call. God may play dice, but I don't like to.
The main point is that languages like C++ make designs possible. The language doesn't dictate the design, the programmer does; the language will do whatever you need for it to do. You can make beautiful designs or ugly ones, the language doesn't care. But it will never refuse to execute your beautiful design just because that doesn't match its opinions about purity.
There are reasons why C++ is the preferred language for difficult problems, and why the highest-paid programmmers all use C++ in their work. It is not because of some shadowy conspiracy dictating the future. Every detail of C++ was chosen for its usefulness first, so each new ISO C++ Standard is more useful and usable than the last. More people pick up C++ to use professionally for the first time each (short time unit) than the total number paid to use (current hipster language). That will be true for a long time.
Most importantly, C++ will never "run out of steam" when your project grows beyond its initial intention.
A screwdriver is not effective at that job, that’s the whole point. A good tool is a suitable and effective tool, not necessarily an aesthetically pleasant tool. Beauty of the tool is not a relevant metric
I'm not sure what you're talking about. You said to stop worrying about tools, and I gave an example where the tool does indeed matter, and then you agree with me but act like you're disagreeing.
A good tool is a suitable and effective tool, not necessarily an aesthetically pleasant tool. Beauty of the tool is not a relevant metric
No one is hinging upon aesthetics. They simply come with tools that have been purposefully designed. I might suggest reading some architecture books, from the older architects like Frank Lloyd Wright, or books on complex systems about the relationship between form and function.
The charitable (and more reasonable) way to interpret 'loving your tools' is not 'liking your tools intensely' but rather 'don't enter into an exclusive romantic relationship with your preferred tools'.
Generally if you can prove your ability to solve problems you get more credibility when deciding the tech stack, but given your assertion elsewhere that "tools are often dictated by those less experienced or even unknowledgeable", then your original question is basically how to prove yourself better than the "middle of the bell curve" under an unfair system.
I mean, the points you raised there are probably factual, but it's apparently not a really helpful (to yourself) way to look at things. Generally smart people are able to surround themselves with similar people, and don't really need to find ways to convince unknowledgeable people that they're smart. Software engineering is a huge field and I'm sure you could find people who more resonate with you.
And sometimes it just takes some years for people to realize you are right.
All that said, I think on the tooling part, it all just boils down to taste. Some tastes are more refined, but they're largely subjective or situational.
paraphrasing Russ Ackoff, intelligent people don't aim to solve problems but to dissolve them, and the best way to do this is to build whatever it is you're building on excellent tools. We would have significantly fewer problems in the world of software if people started paying attention to the quality and mastery of their tools.
The issue is that programmers often focus on the aesthetic aspects of their tools. They like smalltalk and lisp because they are somehow elegant and beautiful. However this is a red herring. The only metric that should be considered is how effective the tool is for solving the problem. Discerning between utility and aesthetics of a tool is an essential skill for any programmer to learn
I liked Smalltalk because the language implementation provided source code for all the IDE tools: examples of how to build rich GUIs when that was new.
I liked Smalltalk because I could watch people working with a prototype and learn how to transform the work they were doing.
I liked Smalltalk with ENVY/Developer because I could see when someone created new unreleased editions of methods on classes that I'd changed, talk with them, resolve clashes, merge and release, in a tight development cycle.
Speaking for myself, utility plays a big role in how I perceive a tool in terms of aesthetics. It's not only about a language's grammar fitting in a business card and stuff like that.
Python and JavaScript are two languages that have been used for stuff they are obviously unsuitable for, at a vast scale.
Scientific computing. I can't just write a "for" loop and expect it to perform. I have to use whatever is provided by packages which weren't written in it, or make a similar package myself.
I can't imagine any technical reason for this situation. Only perceived convenience and some kind of social dynamics.
The Art of Problem Solving is a good start given that most of his other work is more management oriented. But if you want an introduction to his kind of thinking, Thinking in Systems by Donella Meadows is fantastic as well.
Thanks for the suggestion! Yes, I'm familiar with Thinking in Systems and other systems thinkers but for whatever reason haven't read anything from Ackoff.
You can use a language chosen by the middle of the bell curve and still get a lot of satisfaction and success out of being on the right of the bell curve of skill in that language.
There are many mundane C++ programmers out there just getting things done, and there are world experts who always come up with something unique, interesting, and exceptionally valuable to do with it.
Most importantly, what they do has value to their company or even to the whole industry, so they get the full benefit of how popular their technology is while still getting the full enjoyment of doing something clever in it.
If you do want something less mundane than C++, try Rust, it also has a high skill ceiling but you'll spend less of your time fighting tech debt. I think this is the sweet spot for language choice right now, but I can still have a lot of fun writing delicately crafted Go despite the obvious and intentional appeal to the lowest common denominator there.
You can use a language chosen by the middle of the bell curve and still get a lot of satisfaction and success out of being on the right of the bell curve of skill in that language.
This is very good pragmatic and realistic advice and really the only way to stay sane.
If you do want something less mundane than C++, try Rust, it also has a high skill ceiling but you'll spend less of your time fighting tech debt. I think this is the sweet spot for language choice right now, but I can still have a lot of fun writing delicately crafted Go despite the obvious and intentional appeal to the lowest common denominator there.
I personally feel F# is a sweeter spot. Also, I have found Rust jobs hard to get because most positions seemingly want 5-10 years experience. I'm interested in the language but have run out of steam using up my spare time just to learn new languages rather than doing something more interesting or just reading and other hobbies.
Have you found F# jobs more abundant than Rust jobs? We might be in different bubbles. I know F# has been around much longer and is a first-class citizen in Microsoft's ecosystem, but I don't touch that ecosystem much. Shame, too, because I was a Scala fan a decade ago and it was hard to watch that self-destruct, all the while F# endured.
I have found Rust jobs hard to get because most positions seemingly want 5-10 years experience
I would think of that as potential employers screening themselves out without wasting your time interviewing.
The kind of places I've worked already heavily use C++ and Go -- think world-scale production infrastructure with management and control planes -- so many teams adopt Rust in some form at some point. So suddenly a lot of people have, if not outright Rust jobs, then at least jobs where they could spend a large fraction of their time writing Rust, and on exactly the kind of mission-critical performance-sensitive software that Rust is ideal for.
It’s all about doing. Next time you need to prototype something do it in your ideal language (this is the crux as you need to knock it out of the park). The next phase is showing how much more work it would have been in blub. The final phase is being prepared and capable enough to teach your co-workers!
I won't say that the platform is irrelevant, but not the main problem.
You need to be so much more productive than the rest that, after following the usual useless mandatory hypertrophied process, you still have time to apply a sane problem-solving strategy.
That means: make your own tools for the platform you're forced to use.
You need to be so much more productive than the rest that
In my personal experience, one would be surprised about how little that (productivity) matters to people. In my experience, tools are often dictated by those less experienced or even unknowledgeable. Thus, their criterion is based upon what they've heard of and what they perceive their self and others being comfortable with.
Comments
Does anyone have any advice on how to become an auteur software engineer? I've tried visual programming, functional programming, and several others, and they are just so much more enjoyable and powerful (in a specific sense akin to productive) than mainstream languages like Python, C++, etc. But I'm relatively exhausted by having platforms dictated to me by the middle of the bell curve and, frankly, people not experienced. Even as something as simple.and pragmatic as F# or Elixir seems to make people step back from you, as if you're cursed, much less something like Smalltalk. At this point in my career, I have given up and am just going to use Python and C++ like everyone wants you to. It's been a big enough hurdle yo probe that Incan write in Python and C++ despite having used a plethora of languages.
So, how do you use these powerful platforms banished to personal projects? How does one get into a position such that you can dictate the platforms used? Is there anyone who has done this?
It's an unfortunate case of people having the interesting applications having a very tunnel visioned view of what could be with software.
Real programmers can write Fortran in any language.
I don't write Fortran, but I can make my C++ look a lot like a different language. Knowing how those other languages work makes my code better. Sure the C++ syntax is ugly, but the design is what matters and that take inspiration from languages other than C++.
That sounds like the wrong thing to do and a nightmare to encounter. I guess I'm not a "real programmer", which bolsters my original point.
Knowing is good. But it goes both ways as well. But C++ devs are fairly notorious for not liking different things. See Rust's history.
The syntax isn't the point, or is at least a minor one. The main point is that languages like C++ make designing harder than it needs to be. Also, in a language like C++, nearly anything can happen at any moment. It's like rolling dice for every function call. God may play dice, but I don't like to.
The fortran thing is from 1982. Worth a read\laugh https://www.ecb.torontomu.ca/~elf/hack/realmen.html
as for the rest, good or bad idea depends on what you do. Some things are good, some bad.
Ah, I see. Thanks for the reference. I'll give it a read.
The main point is that languages like C++ make designs possible. The language doesn't dictate the design, the programmer does; the language will do whatever you need for it to do. You can make beautiful designs or ugly ones, the language doesn't care. But it will never refuse to execute your beautiful design just because that doesn't match its opinions about purity.
There are reasons why C++ is the preferred language for difficult problems, and why the highest-paid programmmers all use C++ in their work. It is not because of some shadowy conspiracy dictating the future. Every detail of C++ was chosen for its usefulness first, so each new ISO C++ Standard is more useful and usable than the last. More people pick up C++ to use professionally for the first time each (short time unit) than the total number paid to use (current hipster language). That will be true for a long time.
Most importantly, C++ will never "run out of steam" when your project grows beyond its initial intention.
I recommend that you stop loving your tools and focus on solving problems.
And I ask, why not both? It's gonna be a rough day at the job site hanging dry wall with a screwdriver.
There isn't some dichotomy that makes us choose between good tools and solving problems.
A screwdriver is not effective at that job, that’s the whole point. A good tool is a suitable and effective tool, not necessarily an aesthetically pleasant tool. Beauty of the tool is not a relevant metric
I'm not sure what you're talking about. You said to stop worrying about tools, and I gave an example where the tool does indeed matter, and then you agree with me but act like you're disagreeing.
No one is hinging upon aesthetics. They simply come with tools that have been purposefully designed. I might suggest reading some architecture books, from the older architects like Frank Lloyd Wright, or books on complex systems about the relationship between form and function.
I’m clarifying my point. You understand my point now I’m sure. And yes there are many many programmers who get hung up on aesthetics
No, I don't understand your point because you said to stop loving your tools, which I don't agree with.
The charitable (and more reasonable) way to interpret 'loving your tools' is not 'liking your tools intensely' but rather 'don't enter into an exclusive romantic relationship with your preferred tools'.
Generally if you can prove your ability to solve problems you get more credibility when deciding the tech stack, but given your assertion elsewhere that "tools are often dictated by those less experienced or even unknowledgeable", then your original question is basically how to prove yourself better than the "middle of the bell curve" under an unfair system.
I mean, the points you raised there are probably factual, but it's apparently not a really helpful (to yourself) way to look at things. Generally smart people are able to surround themselves with similar people, and don't really need to find ways to convince unknowledgeable people that they're smart. Software engineering is a huge field and I'm sure you could find people who more resonate with you.
And sometimes it just takes some years for people to realize you are right.
All that said, I think on the tooling part, it all just boils down to taste. Some tastes are more refined, but they're largely subjective or situational.
hnfong explained it better than I did
paraphrasing Russ Ackoff, intelligent people don't aim to solve problems but to dissolve them, and the best way to do this is to build whatever it is you're building on excellent tools. We would have significantly fewer problems in the world of software if people started paying attention to the quality and mastery of their tools.
The issue is that programmers often focus on the aesthetic aspects of their tools. They like smalltalk and lisp because they are somehow elegant and beautiful. However this is a red herring. The only metric that should be considered is how effective the tool is for solving the problem. Discerning between utility and aesthetics of a tool is an essential skill for any programmer to learn
I liked Smalltalk because the language implementation provided source code for all the IDE tools: examples of how to build rich GUIs when that was new.
I liked Smalltalk because I could watch people working with a prototype and learn how to transform the work they were doing.
I liked Smalltalk with ENVY/Developer because I could see when someone created new unreleased editions of methods on classes that I'd changed, talk with them, resolve clashes, merge and release, in a tight development cycle.
Speaking for myself, utility plays a big role in how I perceive a tool in terms of aesthetics. It's not only about a language's grammar fitting in a business card and stuff like that.
Python and JavaScript are two languages that have been used for stuff they are obviously unsuitable for, at a vast scale.
Can you give an example of something Python has been used for that it’s not suitable for?
Scientific computing. I can't just write a "for" loop and expect it to perform. I have to use whatever is provided by packages which weren't written in it, or make a similar package myself.
I can't imagine any technical reason for this situation. Only perceived convenience and some kind of social dynamics.
No one brought up aesthetics except for you.
Yes, I know
Which book of his should I start with? Thanks for the reference.
The Art of Problem Solving is a good start given that most of his other work is more management oriented. But if you want an introduction to his kind of thinking, Thinking in Systems by Donella Meadows is fantastic as well.
Thanks for the suggestion! Yes, I'm familiar with Thinking in Systems and other systems thinkers but for whatever reason haven't read anything from Ackoff.
You can use a language chosen by the middle of the bell curve and still get a lot of satisfaction and success out of being on the right of the bell curve of skill in that language.
There are many mundane C++ programmers out there just getting things done, and there are world experts who always come up with something unique, interesting, and exceptionally valuable to do with it.
Most importantly, what they do has value to their company or even to the whole industry, so they get the full benefit of how popular their technology is while still getting the full enjoyment of doing something clever in it.
If you do want something less mundane than C++, try Rust, it also has a high skill ceiling but you'll spend less of your time fighting tech debt. I think this is the sweet spot for language choice right now, but I can still have a lot of fun writing delicately crafted Go despite the obvious and intentional appeal to the lowest common denominator there.
This is very good pragmatic and realistic advice and really the only way to stay sane.
I personally feel F# is a sweeter spot. Also, I have found Rust jobs hard to get because most positions seemingly want 5-10 years experience. I'm interested in the language but have run out of steam using up my spare time just to learn new languages rather than doing something more interesting or just reading and other hobbies.
Have you found F# jobs more abundant than Rust jobs? We might be in different bubbles. I know F# has been around much longer and is a first-class citizen in Microsoft's ecosystem, but I don't touch that ecosystem much. Shame, too, because I was a Scala fan a decade ago and it was hard to watch that self-destruct, all the while F# endured.
I would think of that as potential employers screening themselves out without wasting your time interviewing.
The kind of places I've worked already heavily use C++ and Go -- think world-scale production infrastructure with management and control planes -- so many teams adopt Rust in some form at some point. So suddenly a lot of people have, if not outright Rust jobs, then at least jobs where they could spend a large fraction of their time writing Rust, and on exactly the kind of mission-critical performance-sensitive software that Rust is ideal for.
Absolutely not. Haha. F# jobs are non-existent. I only meant that from a language point of view.
Step one is "get a real day job first", I guess.
(The same advice applies to writing and music too.)
It’s all about doing. Next time you need to prototype something do it in your ideal language (this is the crux as you need to knock it out of the park). The next phase is showing how much more work it would have been in blub. The final phase is being prepared and capable enough to teach your co-workers!
I won't say that the platform is irrelevant, but not the main problem.
You need to be so much more productive than the rest that, after following the usual useless mandatory hypertrophied process, you still have time to apply a sane problem-solving strategy.
That means: make your own tools for the platform you're forced to use.
In my personal experience, one would be surprised about how little that (productivity) matters to people. In my experience, tools are often dictated by those less experienced or even unknowledgeable. Thus, their criterion is based upon what they've heard of and what they perceive their self and others being comfortable with.