The vacancy has expired.
.NET internship is perfect for you if you want to gain more knowledge of how to write clean code. Learn more about .NET and Angular. Gain experience in working with principles such as Test-driven development and pair-programming.
- Solid knowledge of OOP
- Knowledge of .NET and Angular is a plus
- 15 hours work week
- Flexible schedule with fixed-time meetings at the office
Duration: 3 months
Application deadline is 15. November 2019.
You’re finishing your studies and feel that it’s time for testing your skills, learning about cutting-edge technologies, new environment and some hardcore programming?
We are waiting for you!
- Opportunity to work closely with experienced colleagues in a pair-programming manner
- Putting products to production more confidently by having code written using TDD and DDD
- Experience working in a true agile team
- Continuous education through activities such as group reading sessions, subscription to learning platforms and much more
Our typical technology stack looks like
- Spring Boot,
For more information about the technology we use, check our website
- You love programming
- You’re not afraid to dig in deep in JavaWorld
- You’re not afraid to speak your mind
- You’re a team player
This vacancy has expired.
We are looking for a Business Analyst!
You are not afraid to ask Why? You do not rest until everything is clarified? You are continuously optimizing processes? You want to be the glue between the customer and the development team?
If this sounds like you, keep reading.
- Gather requirements from the client, online or live at the client premises (e.g. in Brussels)
- Analyze business requirements and translate them to clear and concise user stories
- Define an “action plan” to deliver user stories by helping the team to break down user stories in tasks
- Analyze requirements and perform feasibility studies with regard to IT applications to ensure that a clear problem definition can be drawn up taking into account possibilities and restrictions.
- Draw up a project definition and functional specifications for projects/programs to ensure that customer requirements can be met taking into account the business strategy of the customer.
- Initiate and follow up projects under the close supervision of the Project Leader/product manager to ensure that a smooth execution of projects can be guaranteed.
- Validate newly developed systems to ensure that a successful implementation is possible in agreement with the set criteria of the (internal) customer.
- Continuously boost and stimulate the development and improvement of quality with regard to the used processes and tools to ensure that the user can be offered the best services and, thus, strengthen the partnership.
- Exchange ideas and expertise with internal and external stakeholders within different disciplines to ensure that you contribute towards the development and the continuous improvement of tools, methods and working procedures of the organisation.
- Stay well-informed about the evolutions and developments related to IT or Business applications, keep his/her knowledge up-to-date within the context of the amendments to regulations in order to strengthen his/her credibility by offering a service that is continuously based on updated knowledge.
- Fluency in English
- Communication skills
- Good analytical and synthesizing skills
- Ability to clearly define problems and requirements and determine solutions
- Experience working in agile software development teams
- Good knowledge of agile strategies
- Practice in writing functional requirements and user stories
- Understanding of SQL
- Experience in Jira or any other issue tracking tool
- Opportunity to excel
Application deadline is 15.07.2019.
Back in 2008 Robert C Martin proposed a fifth value for the Agile Manifesto: “Craftmanship over Execution”. With this value he wanted to tackle one of the main reasons why software fails, situations when teams execute but don’t care.
With this idea the goal is to draw attention to readability, stability and technical excellence. In order to accomplish this, it is often best to have a certain official development culture, with a set of standards and principles, in the team and company.
But that is not always the case. Management often refuses to allow certain practices to become official, but even in such cases, developers should not be stopped in applying them. After all, to become a professional software developer, one needs to start from oneself. Elevating yourself to higher standards can be done even if the surroundings don’t always set the path. There are a lot of ways to help you achieve high quality code without official permission. After all, to became a better developer, you need to take pride in what you do and have something to defend.
Here are three practices, mostly practiced in the enterprise world that can help you achieve better personal productivity:
Boy Scout Rule
Always leave things better than you found them. This rule applies in every part of life and, consequently, in software development. If you are adding a new feature, fixing a bug or refactoring always think how you can improve what you come across.
But be aware, don’t do big changes. If you think something should be improved, but would take a lot of time, propose it for refactoring (just by creating a proposal for refactoring means you are still tidying up the code). Do only smaller changes to what you are originally doing, something that takes couple of minutes, like improving logging message, a better exception handling, create couple more tests for edge cases, break bigger methods in two or more smaller methods, fix the method or test name to be more meaningful, etc.
These kinds of changes don’t take much time, but will drastically improve the quality over a longer period of time.
Test-Driven-Development is a way of designing software by writing test before you write code. The goal is to think about usage of your code before you write it and use tests to think about how it should work. If you do so, you will end up designing APIs and publicly available methods in classes to be cleaner and easier to use. Using some advanced techniques of practicing TDD will help you create highly abstract modules with very high test coverages. With that we come to another product of this approach which is that you will have a lot of automated acceptance tests, edge-case tests and negative test cases that cover your code. Third effect is, such tests can be used as documentation. As I said at the beginning, the goal is to use tests to design classes and modules better.
In practice I saw several bad implementations of TDD. In all of these cases it happened because management decided to introduce it as the official practice in the company. The problem is they thought of TDD as a way to increase the number of tests. And the developers that previously didn’t work using TDD often take that goal as the absolute truth.
They end up hating it because they see it as a push to do more tests. This would result in them refusing to write poor tests, and often write tests after the code, but “selling” it as they are doing TDD.
This is why it is very important to start using TDD and practice it before making it official. The initiative to make it official must come from developers not from management.
One of the biggest issues while working with large enterprise projects is complexity. With time, the technical debt increases, and the code base explodes in size. This makes handling that code harder with time, even when you need to introduce small changes. Even worse, if the code is not written in a way that it can be changed over time by someone who has not written it and there is no one to help them navigate it from the previous team in charge. One of the first goals you need to set is not to become that kind of a developer, who doesn’t care what will happen once they are not there to work or help with the code they wrote.
The best approach here is to always start small, and iterate small. Ignore big details, focus on the smallest details and do them one by one. Ship things early and ship often. Make sure it works and it is covered with tests. The best way to start is to apply the Single Responsibility Principle. The goal of which is to have methods and classes that do one and only one thing. This make them easy to test and easy to use.
By paying attention to detail while writing, you can make it very easy for others to read and understand. Limit yourself by making all methods you write no longer than 6 or 7 lines, and keep classes under a 100 lines. This does mean you will start slow, but you will finish fast. By using a mix of TDD and ADD, you can have acceptance integration tests that will give you the bigger picture and set you on the right path; but when you do small iterations, you write bulletproof classes and modules. Since the devil is in the details, you will stop yourself from producing bugs early on, so by the time you are done, you will drastically decrease the chances of having a lot of bugs, for the QA to have a lot of work and you will not lose a lot of time debugging and fixing edge case bugs by going through a lot of code. You lose much less time by working step by step than by fixing large bugs and edge case problems after writing a large sized code. In time you might find yourself using debugging tools very rarely or not at all!
Author: Adnan Isajbegović