Comment by fefe23 | Hacker News Reader

Comment by fefe23 | Hacker News Reader

I think the creativity thing is a fundamental misunderstanding.

Software engineering is an engineering discipline, not an art. Engineering is about applying the best known methodology to solve problems.

That does not mean there is no room for artistry and creativity.

But most jobs are looking for software engineers, not artists. To them it's more important to have a reliable ETA and get a robust product than for you to find new and creative ways to solve their problem.

Live out your need for creativity in your open source side projects.

Generally speaking: Be creating in WHAT your are doing, not HOW you are doing it. The more creative your methods are, the higher the likelihood of failure. Which is good if your goal was to learn something, but not so good if someone is paying you to solve their problem.

Also note that most software engineering is grunt work. That does not mean it can't be fulfilling, but it does mean you don't have to be a 10x engineer to do it. View software engineering as a great way to make money. Then tend to your needs in your side projects.

I feel like this is the issue with calling most software development a form of engineering. That term has been mostly adopted for prestige or to make it seem much more established than it really is. Certainly in some limited domains, yes, it is engineering and what you said applies to it, for example if you're developing software that controls systems whose failure could result in loss of life then you must be accredited as a Professional Engineer to do that work. But the vast majority of software development does not adhere to engineering principles in the way that civil, mechanical, electrical or chemical engineering does.

For most software projects including web development or CRUD applications, there is no known best methodology to solve problems. Despite how passionate some people are about extreme programming vs. pair programming vs. TDD vs. this vs. that, there is surprisingly little empirical evidence that one methodology is actually better than another. We do what we do out of imitation rather than out of solid and well researched engineering principles.

I beg to differ, it is an art much more than it is about engineering. At least, that’s how I approach my work.

It's sad to put it this way but some "software engineers" roles are essentially like bricklayers: a bricklayer is expected to know how to best lay a brick given the circumstances, or to come up with new techniques to lay bricks faster and better, but they don't need a civil engineering degree to do it.

Other software engineering roles do involve a fair bit of creativity though, e.g. architects (designing the structures), computer scientists (study how to make better bricks), and perhaps also project managers (coordinate brick laying and manage bricklayers).

Can confirm. This is my thumbrule as well.

At any point of time, have two buckets of projects to work on.

#1 projects that lets you apply what you already know and ship fast while being useful in real world (typically dayjob takes this slot)

#2 projects that lets you learn new stuff and think creatively, while affordable to fail or ship slowly (usually side projects)

Following this gives you a balance and avoids burnouts.

i find a lot of the creativity/puzzle solving is in figuring out what they (product + customers) actually want to accomplish and how that models abstractly into computing terms. Once you realize what is being modeled you can often creatively see how given multiple future features are all just a different class of X and can be treated identically/similarly save for a couple of tokens or a slightly different finishing touch

and example might be a permissions feature that could be designed as adding a column to each row, or could be more generalized into a foreign table giving the ability to N:N, or create arbitrary new permissions etc.

Reply on news.ycombinator.com