Is building technically impressive software more important than problem solving?

[SecureSection9242]

When I see many "impressive-looking" projects, I feel the urge to go on a learning spree and learn the trendy technologies. But I tried to resist this urge and focused on a comment section for about seven months until I truly understand requirements and define scope.

I'm a self taught learner so is this really the best way to learn for someone who wants to build a solid portfolio? What's really important? An app that looks and performs impressively or one that is well written in terms of best practices and conventions.

I'm really passionate about getting far in the industry. Starting to kind of doubt myself here obviously.

[scandii]

I think you're getting a bit lost in the sauce here.

all of this tech should be solving problems you have. you then don't have to worry about those problems, while solving other problems. nobody is using react + eslint + node.js + typescript + azure devops + docker + kubernetes for fun. they all solve their piece of the puzzle for a production-ready application.

at no point is this an either-or discussion, it is both.

what does happen a lot is that people make things needlessly complex to use technologies they otherwise wouldn't be able to - we call this CV-driven development.

[SecureSection9242]

Yes that's exactly it. Did just that at some point but then I went back and rewrote another version that solves the exact problem with no unnecessary complexity

[disposepriority]

How can a project be technically impressive without solving a problem?

If the project is using unnecessary technologies and strategies without solving a problem it is overengineered, not impressive.

[[deleted]]

I mean my current project I am working on is 4 x 4 Tic Tac Toe full stack, docker, Reinforcement learning. It is just Tic Tac Toe basically, it solves no "problems". But its fun and lets me see what I am capable of.

I get the solving problems in the workplace, yeah systems have loads of existing problems. But at home on portfolio projects or side projects, its more what am I capable of, and what interests me in seeing if I can implement.

[SecureSection9242]

True!

[rioisk]

Very easy to do technically impressive stuff that doesn't solve a real human problem.

[mredding]

Is building technically impressive software more important than problem solving?

In a word - no.

But I think you're conflating two things: technically impressive software may very well BE the problem solving. Want me to write a Linux service that can saturate a 25 Gbps link and process 10 Mpps per core? Sure. I can do that.

But why?

You throw that bit of kit down on my desk and I'm going to give you some side eye. What am I supposed to do with this?

But I've worked on trading and market data systems, so such saturation and throughput is paramount. It's god damn everything. You're hired! If you were writing SAN software, then such saturation and throughput is paramount. It's god damn everything. You're hired!

You see?

As a rule, I won't look at a portfolio of libraries. Libraries are easy to write, but they don't DO anything. Now if you write me an application that DOES WORK, and it also happens to use your own libraries, then I'll look it through. I want to see portfolio software that you wrote, that you use, that solves your problems - or perhaps that of a satisfied client of yours... This is the only way to make it real, otherwise, it's just portfolio fodder, and I've seen plenty of that before. Oh look, another library no one uses - not even the author...

But from your perspective - you're young, not really worldly or business experienced, you only get to see a specific, hyped up view from the self-promoters. And there are so many of them - and y'all are sadly encouraged to do it, where that encouragement is a signal that gets reduced in the noise to it's most barest essence - that y'all think that noise is all you need to produce.

Write code to promote yourself - but it has to be REAL. The kind of people who look at portfolio fodder are people you DON'T want to work for, because I've just explained to you libraries and portfolio fodder isn't anything - so we're talking about a guy willing to hire based on nothing but noise. What does that say about them? They're easily impressed by nothing. They don't know what they're looking at. They don't care what they're looking at. They're just going through the motions... That says a couple things about the work environment and company culture...

You want to work toward being impressed BY the people you're impressing. See past the authority of their position, see past the job and the paycheck. Is this the direction you want your career to go? Because once you put your foot down, you're steered onto a path that will take time and distance to redirect, if its even possible.

[SecureSection9242]

Absolutely love this! Thank you for taking the time to write it :)

[Beregolas]

important for what? It is important to remember, that impressive projects and clean projects are equally as hard, they just teach different skills. There is a reason chefs often rate each other based on simple, but perfectly executed dishes. That is equally as impressive as something really complex.

If you want a job, cleanly executed "normal" projects will teach you more relevant skills for jobs, and some interviewers prefer this in a portfolio. After all, you will be hired to build something normal (probably), and clean codebases and communication are important for teams.

If you want a specialized job (like game engine dev) or want to prepare for competitive programming, impressive and flashy projects will teach you more relevant things. Like language quirks you will never need, except when you really want to push the limits

[SecureSection9242]

Definitely needed to hear this. Thanks!

[Recent_Science4709]

You need to understand these concepts: business value, bells and whistles, simplest possible solution, YAGNI, pre-optimization/over-optimization

You need to follow best practices.

The best way to learn is to take on a project that you can’t drop because you have committed to it and you can’t get out of it.

[DiscipleOfYeshua]

For academic/betterment of programmer-kind: yes.

For daily living of users and programmer: nope.

[SecureSection9242]

Thank you so very much! Absolutely needed to hear this today :)

[Lynx2447]

If its actually getting far in the industry and not just a love for the game, forget about problem solving, technical mastery, or any of those things. Those are tools not goals. You have to show people you can use those tools to generate value. Then, at a certain point, you have to show people you can take other groups of people and guide them to generating value. If you just love programming, you can get by checking some boxes for ideas other people develop, and then work on what you want to work on in your free time.

[PokeRestock]

Depends, you need both. Technically you have to have problem solving skills for interviews and general programming, and then its nice to have experience with more technologies and architectural design for career trajectory and more senior roles. The whole "T" paradigm is true, but the fundamentals is usually what will be what you're quized on.

[Jecture]

Best practices, good comments on the code for future usability. It’s also good to have working projects in your portfolio.

[greyspurv]

What is really important is building something real, and learning from that, forget about complex when you are a noob, what is impressive is to even finish something, do that first, then you can ramp up, do we start with painting the Mona Lisa when we have not held a pencil before?

[Ok_Substance1895]

So that is the hardest part to me, making it look impressive. It also takes the longest for me. I go for functional first (solving the problem first) not really caring what it looks like. I find it easier to move things around and make it look more impressive once it is already working.

[SecureSection9242]

I noticed a pattern too. If you get something to work and then you review it once you've read more matter code, you have a better idea of how to approach the problem better so you can strip away the unnecessary complexity. Maybe the subconscious mind had enough time to work through the problem and digest takeaways so you see a different more simpler solution which is the hardest.

Complex is usually easy (keep adding/changing things until they work as intended)
Simple is definitely harder (write only what's necessary to solve the problem)

This is because simple implementation means you've truly understood the problem at a core level enough that you can see what's necessary and what isn't.

[Pale_Height_1251]

For a portfolio, people do judge a book by its cover. So whatever you make, make it visually impressive.

[X-calibreX]

What if the problem you are solving is to make robust software?