Answer Type: Development

Last update on

Are There Language Learning Apps That Can Help You Learn Another Language?

None of the “language learning apps” will effectively help you learn a new language to the extent of being comfortable using it in practice.

language learning apps

I’ve studied Spanish and German with Duolingo, Memrise, Babbel and enjoyed different aspects of each app. They weren’t mutually exclusive, either.

Most applications will teach you some basic grammar and a limited set of words and phrases. Some (like Babbel) include basic conversations in their curriculum which is better than nothing.

Unless you supplement your learning with additional reading, watching TV in the foreign language (with subtitles), trying to listen to radio or music, and communicate with native speakers, you’ll be caught off-guard the first time you travel abroad or have a business meeting.

In a natural conversation, you normally have metaphors, idioms, slang, cultural references — tons of context that isn’t taught with apps. Dialects and accents make a huge difference as well. Studying purely from a “textbook” (especially if you skip the voice exercises) will limit you further.

Some training programs require video or audio conference conversations with other students. This actually makes a bit more sense and can supplement the learning.

Note: None of the popular language learning apps is poor per se. They simply don’t help you participate in an actual conversation at the restaurant, at the bus station, in the cab.

You tend to cover a dozen basic phrases which never come up in practice, and get stuck desperately trying to match what you hear to the limited list of phrases you’re prepared to translate.

Last update on

How Do Web Developers Decide Whether To Use CMS Or No Framework?

How Do Web Developers Decide Whether To Use CMS Or No Framework?Here’s A Typical Timeframe On How Web Developers Decide

  • 0 – 2 years of experience: Thrilled about their favorite (and only) framework they’ve ever used.
  • 2–4 years – Frameworks are crap, everything has to be built from scratch, period.
  • 4–7 years – A mix between a couple of frameworks with an unnecessarily complicated distributed environment running behind (probably on top of a blockchain with some attempts at using machine learning for displaying a box on the homepage).
  • 7–10 years – Legit discussions regarding performance, stability, security, interoperability, backward compatibility, and other implications of software architecture over time.
  • 10+ years – Won’t take your project anyway.

Labels aside, developers use what they are most comfortable with for a period of time, or push for a custom build if they are passionate about reinventing the wheel and building something extraordinary.

We’ve been invited to dozens of RFPs pitching 50+ companies. I always ask about other applicants, and usually, hear whatever platform sits well into the portfolio of the business.

Smaller agencies tend to specialize in a specific language/platform. Larger outsourcing companies employ engineers using multiple technical stacks, usually .NET, Java, and PHP or Python, maybe Ruby in some odd cases.

Moral of the Story

https://www.youtube.com/watch?v=0MQfXOEoipY

Most projects can be built-in most platforms out there. While various platforms may be more suitable, the difference is often marginal, unless you have a good reason to prefer a specific stack. And developers/agencies look for themselves, too – they won’t be able to deliver the work on time/budget with less familiar technology, and they push for portfolio and additional experience in their own stack.

Last update on

Is Freelance Trial a Good Transition to a Full-Time Development Job?

This is also a strategy that we apply occasionally.

Our company is based out of Europe and the local employment legislation is more conservative when compared to the US. You can’t just layoff people here and there, and you can’t terminate them on the spot (except for disciplinary actions).

Paperwork is also time-consuming, especially for smaller teams. We work with an external accounting firm and we have to meet every now and then for paperwork related to sick leaves, promotions, and different regulations at the office. Hiring new people takes time and involves the local IRS services.

If we find that an applicant is rock solid and would be a great fit, we send an offer right away. That said, this is rarely the case.

Most companies are looking for very specific profiles.

  • Less experienced people are riskier and may require months of onboarding and training until they get up to speed.
  • More senior folks most likely are looking for higher pay or additional perks – which is an added cost for the team. Some of them are experienced in different fields that are not directly related to the organization’s goals.

And 95% of the candidates are usually in either of those categories.

Especially with less experienced folks, a freelance deal may be a good way to test the waters before committing to a full-time job. It could assess productivity, communication skills, and the culture fit.

It’s not applicable for employed applicants looking for a transition. Most of them are hesitant to leave a job only to engage in a 1-month freelance trial that may fail. Which is odd, because a standard trial may still take 3 months and get terminated before signing the indefinite contract.

However, receiving a freelance offer probably means that the employer is willing to give you a shot and can’t find a better way to commit to a full-time deal. Keep in mind that there are some shady employers that may be exploiting that process – but it’s not uncommon for smaller companies to hire freelancers or consultants on a trial basis before offering a full-time job.

Last update on

How to Handle Code Reviews as a New Software Development Hire?

If that would make you feel any better, nobody wants to be criticized about their code quality. Even more extrovert developers who are confident in their code quality style feel intimidated by code reviews – especially during the first few weeks or even months.

I’ve been in that situation myself plenty of times. I work on projects with different teams, contribute to open source products, commit code when my colleagues are off that may get refactored later.

In fact, I co-authored a major performance patch for WordPress several years ago. The main developer in charge of my review was also hesitant to give a green light due to the risk of ruining the Pages screen for tens of millions of installs. He pushed back the patch until he wasn’t the main lead of that component, approved it, and delegated it to the next guy to take responsibility if something goes wrong.

Luckily, everything went smoothly!

Even if you’re absolutely confident in your code quality skills (adhering to the language/framework standards, implementing the right design patterns, optimizing for speed and security), there are business-specific components that may interact better via different implementations.

Here is what you can do to alleviate the tension.

1. Stick to the coding standards

Every programming language has coding conventions or quality standards. Study them in depth and make sure that you follow them closely.

Organizations may introduce their own standards as well. Make sure you’re familiar and able to follow the conventions accordingly. Read commit logs by other developers and ensure that you are aware of any particular approaches that work for your team.

2. Use static code checkers

There are static code analysis tools available as well. You may integrate them in your IDE or run them from the shell before pushing code to version control.

Some may be integrated as a pre-commit hook or ran as a part of your continuous integration server. Whatever works best, automating certain portions would give you some confidence as well.

3. Participate in peer programming sessions

If possible, participate in peer programming sessions – hackatons, working on new projects, or contributing along other experienced developers in your team.

You can even start a pet project with a friend and work remotely, sharing screen and discussing solutions and implementation live.

4. Work closely with your team

The more you work along your department, the easier would be to align with their process. That is extremely important especially for new hires who need to adjust to the workflow.

5. Regularly ask for feedback

Don’t wait for a code review to happen. Whenever you work on a larger component or you aren’t sure of the best way to implement something, ask a colleague to help and give you some tips.

This type of informal code review will make it easier when going through an official one.

6. Be brutally honest with your reviewers

Before the formal code review, discuss your concerns with your reviewer. Let them know that you’re trying hard and you want to improve. Tell them that you’re hesitant to push code and don’t want to violate any coding standards – let alone cause regressions in the product.

As long as you’re not acting cocky, reviewers may cut you some slack and show you some techniques to get better as well.

7. Suck it up

Regardless of your preparation, the first reviews would still be rough. Some remarks may show up. Code may need refactoring.

But hey, it’s for the sake of improving the entire code base. You will pay some technical debt and improve your skills as well. It’s all good at the end – just pay attention to the comments and make sure that those notices won’t occur again.

Last update on

How To Explain Flaws In a Web Design Provided By a Client?

Thanks for A2A.

For starters, my background is in technology and I’m not a designer by heart. Heck, I am partially colorblind as well which doesn’t help telling between nuances of the green and blue gamma.

With that in mind, I tend to often be on both sides of the table every week.

In either case, I always rely on data and case studies:

  1. Reputable sources on design
  2. Popular brands innovating with modern web concepts
  3. Design competitions and contests
  4. Schoolbooks on design (typography, color schemes, composition, proportions)
  5. Trendy landing pages or designs for sale

I apply that regardless of whether I’m discussing a design with my team or with a client who claims to have an eye for detail.

The first step of establishing rapport with a client is taking a lean and affirmative approach.

If their design suggestion is outdated or outright incorrect, find some common points and use them as a basis. Appreciate their effort and politely include your expertise.

“Seems like a great concept – definitely something that we could work with.”

“I love the color scheme and the typography. Based on working with X, Y, Z, we have to sort out the alignment and the spacing and we’ll get there.”

“That’s a great font you’ve picked for the site! I believe that we can use it as a basis and introduce other modern and innovative concepts that would really make it pop.”

“That’s a pretty solid design you’ve got there. We may have to adjust for your target audience a bit in order to build a stronger bond with your overall brand identity but we’ll definitely use that as a starting point.”

“It seems like you have followed some of the best concepts from material design. Let me iterate with our creative team and propose some additions that would fit perfectly with that and provide outstanding user experience for your clientele.”

You don’t have to tell them that their concept sucks or you’ll redo most of it. But a good word goes a long way – and praising their credentials would make it easier to solidify your work with your practical experience and your own accomplishments.

They have hired you to do some web design work – which obviously means that they trust your expertise. And you’re expected to bring some of it to the table.

Which is where case studies and practical use cases come in play.

The second step is backing your data with some notable advice and expertise from the best players out there.

When we pitch some design concepts to a problematic client (often claiming to have some design background) we:

  • Provide a portfolio of successful businesses targeting the same audience that follow most of those ideas.
  • Point to industry sources and research papers discussing the proper selection of a color scheme or the right fonts.
  • Outline specific spacing problems or layout hiccups that violate the best industry practices.

Hard data is really hard to argue against – even in the web design field where everything could be “subjective” in a creative mind’s head.

But web design is still aiming for results. It is designed to sell. And that also incorporates a lot of insight from the marketing world, branding, user experience, even behavioral psychology.

And your client is hardly a master in all of those areas. So using some practical tips and proven suggestions works really, really well.

Whenever a mockup targets a page where you can track conversions, you can try to do an A/B test. If designs aren’t too far apart, build two identical pages that differ a bit (or more) and measure conversions. Best-case scenario, your expertise have led to a better converting page that sells more – which is an indisputable truth that your client has to accept.

Related: Mario Peshev’s answer to What if the best way to approach your boss or client if their idea won’t work?

Last update on

How Software Developers Communicate Work and Estimates With Managers?

Non-technical managers and clients are not familiar with the implications of a quick patch when compared to a quality build.

As a software engineer, you can easily explain the complex features with real-world examples or enumerate the things you have to build in order to deliver a given component or a project.

My cheatsheet when talking to clients covers three main areas: Stability, Speed, Security. Those are inevitably related to over 90% of the use cases.

If your manager has a hard time justifying the development time, explain to them what the alternatives are and why your solution is the best one. Examples:

  1. Unless we build that specific security layer, the new form would be a subject to XSS attacks/SQL injections. Simply put, a 14-year-old would pick a random script online, run it against the website, and fetch a list of all users and passwords. This extra layer can be leveraged by other user-faced forms across this component.
  2. We can go for a simple workaround but this would impact the load times. Once we hit 100 records in the backend, the pagination will start misbehaving. With 500 records, the component will load in 20 seconds which will irritate our users.
  3. This new build will take 60 hours which also includes the module for handling user roles and capabilities. Omitting this one will lead to regressions and missing components for specific users. We can’t handle thousands of different use cases without incorporating the right programmatic logic that would route those requests and serve as a dispatcher – just as the air traffic controller makes sure that there are no CNN news waiting for an explosion next to JFK.

The key is in reviewing the available alternatives and explaining the consequences and possible regressions using a human understandable language.

  • Provide real-world examples.
  • Point to specific features that would break otherwise.
  • Mention constraints and limits that a simple build will introduce.
  • Discuss areas related to the key features of the platform and stress on the possible implications.

Non-technical people are not idiots – they simply have no clue what happens behind the scenes. They don’t get operating systems, networks, databases, application layers.

But a feature takes time because it requires a set of algorithms that take care of different problems. Explain the essence of those problems and why those methods/classes/libraries are paramount for the ongoing development of the platform.