werbel

Yes, completely agree and thank you for expanding.

I mentioned the absolute minimum so there's no excuse. At the same time, even a robotic, automated reply is infinitely more than nothing.

Congratulations on having already couple of years of experience at your age. I've been on the same boat 10 years ago.

As for 10, 15, 20 years of experience: As long as you make sure it's actual 10 years instead of 1 year repeated 10 times you mostly gain awareness and intuition for engineering on a higher level of abstraction as well as the place of technology in a broader business context.

Ruby, Django, MVC, Elixir, TS, React, Vue, functional programming, immutability... specific things, tools, technologies, approaches are becoming less important. The experience is getting transferable and you learn when it makes sense to code the Rails way in Django.

Slowly "I'm going to learn React/Vue so I can do front-end" will become "I have to do front-end so I'm going to use React/Vue". When choosing technology you'll realize that the "job" in "finding the best for the job" is not just delivering the solution. It's making sure the solution is easily maintainable for years. In that timescale stack homogeneity, hiring strategy etc sometimes become even more important than the tech fit. You might think serverless is the way to go for your new task. But is it really worth to introduce go lambdas to the system when you already have 20 ruby devs?

I recommend early switch from "I'm an engineer, let me know what to code" to "I'm here to grow the product/business, let me see what I can do". No one pays for delivering code, companies pay to to solve business problems. The problems you solve don't have to be contained to those that come with your job description and the solutions doesn't have involve technology. No matter the aspect of the inner workings of a company (or life in general), everything can always be improved. Identify the things, suggest/provide solutions and you'll be both satisfied and rewarded.

Good luck! :)

This is what I consider to be a "plan":

Problem definition Product solution Technical solution Task breakdown (optionally: > Estimation > Timeline)

Of course there's always some feedback loop between items in the sequence but for given scope it's a good idea to minimize it.

Or in other words: Pick a scope/feature/project, let's say proof of concept for your initiative. It seems like your problem description is robust enough so let's skip to Product solution.

It's a good investment to define everything you can define before stating actual implementation. If you still have some questions to answer then get the answers if that's possible. People have the tendency to leave the "unimportant" details for later but there's no gain in that. You have to spend the time sooner or later anyway. Better to do it sooner because sometimes the "unimportant" detail forces you to go back and rework bigger part of your solution.

Have your entities defined, user stories, UX mock-ups ready before working on technical solution.

Have a technical solution described and validated before you start implementation.

This way you mitigate the risk of being forced to go back to previous steps wasting time or being stuck with sub-optimal solutions.

So regarding the parent comment. If you know enough from the users/market research/cogitating to be reasonably sure about the next step then execute it. Once you get there it's time to continue the research with what you already have in mind.

Otherwise you risk getting stuck in an endless loop of tweaking and changing decisions without reaching tangible milestones.

Your comment sounds like it's an exceptional achievement that in Germany the value is half of the USA.

When in fact it's the US that's embarrassingly low on the list: https://en.wikipedia.org/wiki/List_of_countries_by_infant_an...

Let's skip the top countries like those in Scandinavia, Japan, Singapore, Germany and Switzerland. Belarus, Latvia, Lithuania, Poland, Serbia, Bosnia and Herzegovina are all above USA.

Other people in the thread gave solid advice and things to consider about how to handle that within the company.

Obviously it might not be valid choice for you but I'll expand on an idea of changing companies by describing some of my experience within a company of which management showed unique level of integrity.

The company was Base CRM (now Zendesk Sell). I joined quite early in my career and the company life and it definitely shaped me as a professional.

There was no need to talk much about values because the management clearly lived by them. Transparency and constructive, direct communication was the core. I've never felt out of loop, employees were treated like partners when it comes to access to information. There was rarely a need to ask questions because any piece of information that might be of interest to anyone was proactively presented. Whether the situation was great or not I've never felt something is hidden me. Even when there was a need to make cuts including parting ways with some people I believe most of the company didn't feel angry or frustrated as we had the full context on a daily basis and really felt that they've done what they can to do right by everyone.

I've felt safe delivering constructive feedback directly to everyone, even management. When I made a mistake to discuss something I didn't like in CTO's behaviour to executive closer to my team the reaction was honest and clear: "Yeeaah, but why are coming with this to me?". We've quickly resolved the issue with the CTO directly afterwards.

I'm terribly lucky and grateful to have had a chance to grow in such environment. It taught me that even if the company is not so small it still can be flat in practice, with no visible politics, everyone committed to finding best possible solutions for given problems as long as the management share a common set of values and have common goals.

I assume you raised through the ranks because of your contributions and not by politics. You grew vertically on the professional field. Surely there's enough of things you've done you're proud of and would be solid points on your resume. Maybe at some point it would be a good idea to also grow horizontally by finding a leadership position in some other company.

Feel free to shoot me an email if you are interested in more details or... anything. :)

This is exactly how it works for a Polish minute car rental service Traficar.

You can even drive through the whole country to another Traficar service zone, leave the car there and get back by train.

Yes, I realize not all of us have the luxury of being part of organization where direct, open, constructive feedback whether it's positive or negative is just a thing people do. (Many organizations will boast about values but not live them. If you live them there's no need to even talk about them.)

1:1 or not, good manager should not only make everyone safe with giving him/her and everyone feedback but also ask for it if he/she takes the responsibility of taking care of the people seriously.

Even if that's not a part of the culture then it seems to me it makes sense to try to be the leading example (with a clear, expressed explicitly if needed intent of doing this to make everyone's life and cooperation better) if it doesn't put your job at jeopardy.

However, if it is, maybe it's worth considering what future lies ahead for you in the company? This of course depends on personal goals.

* Performance (e.g. challenges, obstacles, short/long term goals, feedback, productivity)

* Professional development & engagement (e.g. professional goals, training, engagement, coaching)

* Contribution to company growth (e.g. process improvement, supporting colleagues, training pilot/ buddy programs, any other activities)

* Things done / achievements since last 1on1

* Feedback for the manager (e.g. what he/she could have done better/differently since last 1:1, what you/the team is missing)

In summary: What can be done for you, the team and company aside from just "correct individual contribution".

Try to avoid discussing things related to lifecycle of ongoing projects. Those should be handled within your team's standard execution flow. If there's need to talk more on a 1:1 then probably you have a gap there.

Of course in an ideal world in a company that supports ongoing feedback and people are not afraid to raise any issues on a daily basis it should be just: "Hey, do you have anything to talk about? - Nope, everything we discussed on a daily basis. - Ok, same here".

In the real world, there are always things which "there's never a good time for" and periodical check-up is useful for that just like a team retrospective.

I understand that and that's why I haven't said there's anything wrong with your opinion or that I disagree.

Yes, we'd all love to have our tools (repository, package hosting, CIs, ...) both satisfying our needs and be free of whims of for-profit companies.

Some of us simply don't care that much as long as what we have now works and I just wanted to append that to the conversation.

That's why I only said that your message reads like... and not assumed you really believe the service is bad in overall just because it's bad within scope of one aspect that's close to your heart. :)

I'm not saying "open development" is not important but your message reads like its dismissive of people with different goals.

I'm a developer, I might create some tool for my needs and share it with others. I've got other income sources so there's no need for me to charge money for it. I just put it on GitHub as the easiest thing I can do to allow others benefit from it.

In some sense I would be open source developer. I don't care about "open development" though, I don't spend time pondering about software philosophy and its place in the world.

If there's a will to donate some money to me so I can justify spending some more time on the tool to make it more accessible in any way then I want the simplest way for both sides to facilitate the transaction.

Same goes for me being on the other side. I see a library I'd like to use, I believe author(s) made a good job, I'd like the library to be maintained, I want to pay for that with as little traction as possible. I don't care if the author created the library because he believes in "free software" or was simply bored and again, GitHub was the most convenient channel to share.

The same way I don't care what philosophy lies beneath music producer's work and what tools do we use while I'm paying him for his tutorials as long as it works for both of us.

You're right. I should've put "For the most part" before the last paragraph.

When it comes to the moon landing or the ISS... Of course you can say that's because we're explorers. The moon landing was pure survival (don't let the commies win), ISS is research and maybe the researchers put in the effort for a sense of discovery but the money comes from governments and it flows mostly because of a promise of economic or military advancement.

I'm not a cynic in that regard. I love the architecture of religious monuments, I love the fact that we as a species achieved magnificent things like reaching the moon or discovering how black holes work. You can appreciate all of that without kidding yourself about where the money comes from.

I suggest watching following video of Neil deGrasse Tyson: https://www.youtube.com/watch?v=joARXZagTuM

It opens with following conclusion: There were only 3 bottom-level motivators where it comes to achieving grand things in human history: * Survival * Wealth * Praise of deity

There are things people still do that span generations to satisfy the first 2 drivers (like Norway being cautious about its oil reserves or overall push towards clean energy and mitigating climate change, China's investment in its own and Africa's infrastructure).

People simply got smart enough not to throw monumental amount of effort and resources to please a deity. Of course that's a massive simplification as then there's a question if the organisation that "wrote the check" really did that purely because of the spiritual beliefs of their own or their people.

My guess is no one will look back and say "Huh, he was right".

The only thing that probably is going to happen is "Huh, why isn't that delivered?" and then they will look everywhere but on the fact that it was, at least partially, just a stupid idea in the first place.

Of course I don't know the exact situation so it's more of a thought on what happens in general in the industry.

Those options are presented to users who click on the words “Need help?” in one corner of the page.

Hiding something under completely unrelated link is not presenting your options in any way which is remotely close to being honest.

Hah exactly :)

Same goes for functions, classes, React components, DB tables and everything else.

Just model it as close as possible to the real world. The world doesn't really change that often. What does is how we interpret and behave within it (logic/behaviour/appearance on top).

If you have a Label and Subheader in your app, create separate components for them. It doesn't matter that they look exactly the same now. Those are two separate things and I guarantee you more likely than not at some point they will differ.

My rule of thumb is: If it's something I can somehow name as an entity (especially in product and not tech talk) it deserves to be its own entity.

I disagree that it isn't a software bug.

"The new RLP code also repurposed a flag" - this is the moment when terrible software development idea was executed that resulted in all of the mess.

Of course I don't know the full context and maybe, just maybe there was a really solid reason to reuse a flag on anything.

What I observe more often is something like this though:

  1. We need a flag to change behaviour of X for use case A, let's introduce enable_a flag.
  2. We want similar behaviour change of X also for use case B, let's use the enable_a flag despite the fact the name is not a good fit now.
  3. Turns out use case B needs to be a bit different so let's introduce enable_b flag but not change the previous code so basically we need them both true to handle use case B.
  4. Turns out for use case A we need to do something more but things should stay the same for B.
  5. At this point no one really knows what enable_a and enable_b really do. Hopefully at least someone noticed that enable_a affects use case B.

What would probably be even better is separate, properly named config flags for each little behaviour change and just use all 5 of those to handle different use cases.

edit: formatting

Some people just want to call, text, use Google Maps and occasionally browse Instagram and simply don't need the "much more".

I also simply have small hands. I can't comfortably reach left side of a keyboard with my thumb while holding the phone securely on anything bigger than SE so things like Reachability don't help at all.

I'm sorry to be that guy, but if you properly read even just the submission title you'd know it's not about people that are still using Facebook but people that are using other apps like Yelp. That might include you.

Actually because of the diesel scandal VW is the best positioned "normal" car company for a success in EV market at this point.

In order to recover their image they were forced to announce and actually work on full line-up of electric vehicles and their target is 2020. Even with delays that's going to be sooner than any other company. They've been working on the technology for quite some time. Porsche Taycan and Audi e-tron are to come out this year AFAIR.

Also those are EVs that actually look like cars and not kitchen appliances from Axiom (Wall-e movie spaceship) which is something I also think is missing from the market. I can't comprehend what the car companies try to achieve with the designs and separate models.

Right now I can choose between petrol and diesel for my Golf, Volvo V40 or Hyundai Elantra. Just add electric power train to the offering and be done with it. I want EV for the performance, cost savings, environment or whatever other reason might be but I don't want any of the dorky design cues most EV vehicles present.

EDIT: typo

I remember 2005 when was running Windows with Linux in a VM, Photoshop, Firefox, my Rails application and all of the other software I needed for development, music and everything else on a 1GHz AMD Athlon and 256MB SDRAM.

When it comes to software that’s not games and stuff like video editing it seems to me like the most of what happens is “It takes time for new software/updates to show up that once again are able to waste the full extent of my newly acquired processing power”.

I know we get more robust games now, I know we render 4K videos instead of 460p, I know we display UI on higher resolution screens but there’s really no excuse for a software with similar feature scope to take the same resources percentage of modern top of the line hardware as mid-tier 18 years old machine.

Bummer ;(

As others mentioned there’s an aspect of efficiency there but I think there’s something more important.

The whole discussion revolves around losing weight while diet and nutrition is not really about that. It’s about how to eat to stay healthy. Not being obese is just a part of that.

If you consider the bigger scope you’ll realize that despite the fact it came out from Neil deGrasse Tyson mouth, in this context it’s just a stupid thing to say.

I started my engineering career as a front-end developer when being front-end developer meant slicing PSDs to HTML trying to figure out the best way to implement crazy glassy and shadowy designs without transparent PNG support in IE6.

Starting using CSS Modules "properly" with custom built UI components library was definitely the biggest single improvement in easiness of delivering stuff I've experienced across the "whole stack", from the hosting situation, DBs, through popularization of MVC on the server and client side, micro-services to react itself.

Please do give a try. :)

One rule of thumb I passed on my friend learning working with CSS Modules: Never share styles between components.

Sometimes it's very tempting but instead try to compose your components in different ways.

You might want to share style or create mixin for white box with a border and shadow for 2 very similar components. Creating WhiteShadowedBox component even if it's a div with 3 lines of CSS is fine and will save a some headache later. Of course needs a better name. ;)

It's fine to use variables and mixins for "style config" like colors, font definitions, margin scales (0.8rem, 1.2rem, 1.6rem) etc but in my experience not much more.

You're completely right, sir.

I discovered Hummingbird when looking for alternative music notation for my tattoo (a phrase from my piano song).

After reading the "docs" it was easy to read the notation but for some I struggled with transcribing it. Maybe it'd be easy to first write classical notation and then change it to hummingbird.

Also just noticed that even in the toggle example on the home page "natural" symbol is missing (flat/sharp reset).

Each phone ping, like, comment, reply, follow is a dopamine shot.

You know what else gives people dopamine shot? The next piece of chocolate cake, the cigarette that's always overdue, having the drink after long day of work, finally being able to hit the bong and so on.

"Social media" is as much of an addiction on a biological level as drugs. We know that prohibition doesn't work.

We should start with helping people find ways to feed their (dopamine) reward system with more meaningful stuff. Help accomplish them small and bigger things, promote real human interaction.

We do agree 100%. :)

I didn't say to do that against the policy. What I meant was if your company simply doesn't have a habit of doing it just say: "Hey, can I write some feedback and provide some resources to that candidate in your rejection message?".

Edit: My intuition is most companies don't provide the feedback because simply they don't see a value in the time spent or simply never really considered that as there are always other things to do than think about people you'll probably never meet again.

I've rejected dozens of people right after face to face coding session of a simple task (third meeting, first technical) explaining the reasons, providing them some guidance on what to tackle next, if I saw hope invite them to try again once they feel they filled the gaps or at least describe the progress and ask if we think it's enough to try and/or what could be next.

I've most likely never had a person who left without a handshake with a sincere smile on his/her face and most of them expressed their gratitude.

Sometimes you have to reject a person on what you feel is a gut feeling. It's because over time you developed an intuition which is picking small details in a less conscious manner. In the end there are some reasons your intuition is shaped that way not the other and you can find something that presented within the context of your company and expectations will resonate with the candidate and he won't feel like he's been scammed.

If someone told me that in my country (or maybe just outside US) I would simply not believe them at first. It might just be the choice of companies I've worked with though.

It is sad indeed.

If you/your company doesn't have a policy of sending personal feedback please consider doing this at least for junior people. Volunteer your after work time if needed.

Trying to find the first job is extremely stressful process. A junior person has no notion of his worth on the market. Each rejection even if only by a lack of any response ("I'm sorry, I'm afraid we are looking for a bit more experienced person" would suffice) can be like a kick on the face when you're just barely learning to walk and most likely is a burned bridge.

I've mentored my girlfriend for 3 years from almost 0 to getting her first job in a company run by a React Native core developer. She had the skill, great attitude, really solid work ethic and very analytical thinking. It'd trust her more with any task than significant number of my past and current senior coworkers. It's hard to prove and no one expects that so naturally her applications had been ignored or rejected. With each one I saw her confidence, self-esteem and enthusiasm crumb. With each positive reply/invitation she was invigorated until the next step came. I'm pretty sure for some the roller-coaster or even worse, being rejected over and over again can be a life defining experience.

Any reply is great, personal is even better. If you spend time describing what was missing from the expectations of your company (don't say "You don't know enough", say "We need someone with more knowledge") and sincerely wish the person well you can be sure they'll be grateful, remember you, work on the gaps and who knows... maybe some day become part of your team.

Please feel free to reach out if you want some example for inspiration.

Edit: Please don't do that against the policy of your company. But if there are no reasons against just ask if you could provide some feedback and resources for the rejection letter.