I'd argue that if you only know how to start your own project using the play button, then you aren't a software engineer.
I've written a pretty big application for my employer in visual studio. Never once have I run a "dotnet build" command. Only ever used the little play button. Guess I'm no software engineer
The real software engineers are those who can 2 minute Google "how to build with cli" their Hello world console app.
But you knew about dotnet build
Tbf, I looked it up on Google. I know you can do everything you can with Visual Studio also in the CLI, but never bothered checking out the specific commands. 2 second search on Google returned donet build.
A software engineer isn't defined by what commands he knows or what functions he can remember off the top of his head or what languages he used to write hello world. Those are easily Googlable things that have little to no value irl. The ability to actually solve a problem or build an architecture, a system, even if only in pseudocode is much much more valuable than knowing any specific command.
Case in point, I routinely Google stuff I already used or self reference previous code I've written cause I can't remember how I did certain things. Nothing wrong with that.
There's no shame in being a play-button corporate programmer who's in it only for the money! In fact, most employers prefer this kind of people.
Knowing how to do something in the CLI and choosing to use the gui is different than only being able to use the gui.
I don't. Looked it up on Google, not that hard. I also never use git from the terminal, I know I could, but I don't and if you were to ask me off the top of my head how to use it from the cli, I probably wouldn't be able. Not because I can't use git, I just can't be bothered to remember all the commands when a gui is available and does the exact same thing I needed to do anyway. If and when I'll need to use the terminal for git, I'll check the docs for the exact syntax.
Again, knowing the exact syntax it's not what defines a software engineer, IMO.
Then yes, you are not a software engineer. You used programming to solve one problem one time and you didn't understand what was happening under the hood. Building one deck does not make you a carpenter. Writing one app does not make you a software engineer.
Yeah... that's literally my job... but keep on gatekeeping, don't let my existence stop you.
The point isn't whether you use the GUI. The point is whether you are capable of doing your job without it. I'm not going to throw shade but personally I hate being at someone else's mercy - such as when the GUI breaks and I am forced to wait for someone else to fix it. One reason I stay away from the JavaScript browser/electron ecosystem is because there are so many opaque, inscrutable tools (namely bundlers and module resolvers) and I have no freaking clue how they work under the hood and they're virtually impossible to debug.
I'd argue that if you only know how to start your own project using the play button, then you aren't a software engineer.
I've written a pretty big application for my employer in visual studio. Never once have I run a "dotnet build" command. Only ever used the little play button. Guess I'm no software engineer
The real software engineers are those who can 2 minute Google "how to build with cli" their Hello world console app.
But you knew about
dotnet buildTbf, I looked it up on Google. I know you can do everything you can with Visual Studio also in the CLI, but never bothered checking out the specific commands. 2 second search on Google returned
donet build.A software engineer isn't defined by what commands he knows or what functions he can remember off the top of his head or what languages he used to write hello world. Those are easily Googlable things that have little to no value irl. The ability to actually solve a problem or build an architecture, a system, even if only in pseudocode is much much more valuable than knowing any specific command.
Case in point, I routinely Google stuff I already used or self reference previous code I've written cause I can't remember how I did certain things. Nothing wrong with that.
There's no shame in being a play-button corporate programmer who's in it only for the money! In fact, most employers prefer this kind of people.
Knowing how to do something in the CLI and choosing to use the gui is different than only being able to use the gui.
I don't. Looked it up on Google, not that hard. I also never use git from the terminal, I know I could, but I don't and if you were to ask me off the top of my head how to use it from the cli, I probably wouldn't be able. Not because I can't use git, I just can't be bothered to remember all the commands when a gui is available and does the exact same thing I needed to do anyway. If and when I'll need to use the terminal for git, I'll check the docs for the exact syntax.
Again, knowing the exact syntax it's not what defines a software engineer, IMO.
Then yes, you are not a software engineer. You used programming to solve one problem one time and you didn't understand what was happening under the hood. Building one deck does not make you a carpenter. Writing one app does not make you a software engineer.
Yeah... that's literally my job... but keep on gatekeeping, don't let my existence stop you.
The point isn't whether you use the GUI. The point is whether you are capable of doing your job without it. I'm not going to throw shade but personally I hate being at someone else's mercy - such as when the GUI breaks and I am forced to wait for someone else to fix it. One reason I stay away from the JavaScript browser/electron ecosystem is because there are so many opaque, inscrutable tools (namely bundlers and module resolvers) and I have no freaking clue how they work under the hood and they're virtually impossible to debug.